SQL Server JDBC SendStringParametersAsUnicode 導致查詢效能嚴重下降問題分析

案例背景

• 現象：Java 應用透過 JDBC 查詢，尾數為 9 的資料極慢，其他尾數正常
• 排除：資料分佈均勻、SSMS 直接查詢快、網路正常、不同伺服器測試正常
• 鎖定：PreparedStatement.setString() 組裝參數時極慢

根因發現

JDBC 驅動預設 SendStringParametersAsUnicode=true，將字串參數傳為 NVARCHAR (Unicode)。資料表欄位為 VARCHAR (非 Unicode)，導致隱含轉換，使索引無法求用 (Index Scan 取代 Seek)。

驗證過程

1. 完整 SQL 字串直接執行 → 快 (索引 Seek)
2. JDBC setString 參數化 → 慢 (索引 Scan，隱含 CONVERT_IMPLICIT)
3. 發現：尾數 9 無關，實為參數資料型別不匹配導致全表掃描

解決方案

方案一：連接字串關閉 Unicode 參數 (推薦)

jdbc:sqlserver://host:1433;DatabaseName=MyDB;SendStringParametersAsUnicode=false

方案二：資料庫欄位改為 NVARCHAR

• 儲存空間翻倍，但避免轉換
• 適用於多語系、新系統設計

方案三：應用層明確指定參數型別

PreparedStatement ps = conn.prepareStatement(sql);
ps.setObject(1, paramValue, java.sql.Types.VARCHAR);  // 強制 VARCHAR

效能影響對比

最佳實務

1. 新專案預設 NVARCHAR，連接字串保持 true
2. 存量 VARCHAR 系統：連接字串加 SendStringParametersAsUnicode=false
3. 定期檢視 sys.dm_exec_query_stats 找出 CONVERT_IMPLICIT 計畫
4. 資料型別一致性：應用參數型別 = 資料庫欄位型別 = 索引鍵型別

啟示

「SQL Server 客戶端查詢正常，程式組裝 SQL 慢 → 檢查參數資料型別是否導致隱含轉換破壞索引」