SQL Server 資料型別轉換完全指南：顯式轉換 (CAST/CONVERT) vs 隱式轉換風險與實戰陷阱

T-SQL 中資料型別轉換分為 顯式轉換 (開發者主動呼叫 `CAST`/`CONVERT`) 與 隱式轉換 (引擎依優先順序自動轉換)。隱式轉換雖便利，卻藏著型別優先級導致的查詢失效、索引無法求值、效能退化等陷阱。本文系統整理轉換語法、隱式轉換風險實測與最佳實務。

一、顯式轉換函數

常用 style 範例：

• CONVERT(VARCHAR(10), GETDATE(), 120) → `2024-01-15` (YYYY-MM-DD)
• CONVERT(VARCHAR(20), GETDATE(), 121) → `2024-01-15 14:30:45.123` (含毫秒)
• CONVERT(VARBINARY(MAX), 'Hello', 1) → `0x48656C6C6F` (含 0x 前綴)

二、隱式轉換規則與風險實測

規則： 低優先級型別自動轉換為高優先級型別 (如 `smallint` → `int`、`varchar` → `nvarchar`)。

實戰陷阱：混合型別主鍵欄位導致查詢失敗

場景： 表 `Demo` 有 `混合ID NVARCHAR(50)` 主鍵，儲存 `INT` 轉字串 (如 `'305'`) 與 `UNIQUEIDENTIFIER` 轉字串 (如 `'4C185367-F004-41FE-8A0A-DB4E819B1FF2'`) 混雜值。

查詢： SELECT * FROM Demo WHERE 混合ID = 305 (未加引號，數字常值)

執行過程：

1. 引擎依優先級：`INT` (優先級 16) > `NVARCHAR` (優先級 23) → 將欄位 `混合ID` 隱式轉換為 `INT`。 2. 掃描索引/資料頁，嘗試將每列 `混合ID` 轉 `INT`。 3. 遇到 GUID 字串 → 轉換失敗 → 拋出錯誤：在將 nvarchar 值 '...' 轉換成資料類型 int 時失敗。

正確寫法對照

三、隱式轉換的效能副作用

• 索引無法求值 (Index Scan 取代 Seek)： `WHERE varchar_col = 123` 導致欄位隱式轉 `INT`，索引失效。
• CONVERT_IMPLICIT 出現在執行計畫 `Compute Scalar` 運算子，增加 CPU 開銷。
• 參數嗅探搭配隱式轉換可能產生嚴重參數敏感計畫。

四、最佳實務檢查清單

1. ✅ 永遠使用顯式轉換：`WHERE col = CAST(@param AS target_type)` 或 `WHERE col = 'literal'`。
2. ✅ 參數化查詢：應用層傳遞強型別參數，避免字串拼接 SQL。
3. ✅ 設計階段拒絕混合型別欄位：單一欄位單一語義型別；需多型別時建立子表或 JSON/XML 欄位。
4. ✅ 定期檢視執行計畫搜尋 `CONVERT_IMPLICIT`，針對高頻查詢修正。
5. ✅ 跨資料庫/連結伺服器查詢 更需顯式指定型別，避免遠端隱式轉換行為差異。

「顯式優於隱式」不僅是程式碼可讀性原則，更是 SQL Server 穩定效能與正確性的基石。