MyBatis JDBC 執行語句 Unicode 編碼陷阱：sendStringParametersAsUnicode 參數深度解析

現場還原：更新語句執行計劃異常緩慢

SQL Server Profiler 捕獲的參數化語句：
jdbc:sqlserver://127.0.0.1;databaseName=mydb;sendStringParametersAsUnicode=false

修改後 Profiler 捕獲：
  
    參數值行為適用場景副作用
  
  
    true (默認)所有 String 參數作 NVARCHAR 發送表列多為 NVARCHAR、需存儲多語言字符與 VARCHAR 列隱式轉換，索引失效
    falseString 參數作 VARCHAR 發送 (按連接字符集編碼)表列為 VARCHAR、純 ASCII/單字節字符集無法正確傳輸補充平面字符 (Emoji、生僻漢字)
  


最佳實踐策略

  
統一表列類型： 新系統優先用 NVARCHAR，保留 true 默認，避免編碼轉換困擾。
  
存量 VARCHAR 表： 連接串加 sendStringParametersAsUnicode=false，同時確保 Java 源文件編碼與 DB 字符集一致 (如 GBK/UTF-8)。
  
混合場景精細控制： MyBatis 映射中顯式指定 jdbcType=NVARCHAR 或 VARCHAR，配合 typeHandler 強制參數類型，不依賴全局開關。
  
驅動版本： 升級至 mssql-jdbc 12.x+，修復了早期版本 Unicode 參數處理的多個 Bug。


擴展：MyBatis typeHandler 精細控制
Using sendStringParametersAsUnicode
  
Microsoft Docs: Data Type Support for the JDBC Driver


總結
sendStringParametersAsUnicode 是 SQL Server JDBC 連接池與表列字符集匹配的關鍵開關。默認 true 適用 NVARCHAR 表，VARCHAR 表必須設 false，否則隱式轉換導致索引失效、性能雪崩。建議在架構階段統一字符集策略：全庫 NVARCHAR + 驅動默認 或 全庫 VARCHAR + 連接串 false + 編碼一致，避免混合模式帶來的維護地獄。