MySQL 隱式類型轉換導致索引失效：慢查詢根因深度剖析

現象還原：一個引號引發的災難

案例一：VARCHAR 列未加引號 → 全表掃描

-- 表結構：appkey VARCHAR(20) 主鍵第一列
-- 錯誤寫法（無引號）
EXPLAIN SELECT * FROM appstat_day_prototype_201305 
WHERE appkey = xxxxx AND day_key BETWEEN '2013-05-23' AND '2013-05-30';
-- type=ALL, rows=19,285,787  全表掃描！

-- 正確寫法（加引號）
EXPLAIN SELECT * FROM appstat_day_prototype_201305 
WHERE appkey = 'xxxxx' AND day_key BETWEEN '2013-05-23' AND '2013-05-30';
-- type=range, rows=1  索引生效！

案例二：BIGINT 列加引號 → 索引仍生效（但有隱患）

-- 表結構：poll_id BIGINT 有索引
SELECT * FROM poll_joined_151 
WHERE poll_id = '2348993' AND anonymous = 0 
ORDER BY add_time DESC LIMIT 3;
-- type=ref, rows=30,240  用到索引，但掃描行數較多

根因：MySQL 官方隱式轉換規則（5.5 文檔）

若比較雙方類型不一致，MySQL 會將雙方**統一轉為浮點數（DOUBLE）**再比較。
字符串轉浮點數規則：從左到右讀取數字字符，遇非數字停止。
'1', ' 1', '1a' → 均轉為 1.0

為何 VARCHAR 不加引號會失效？

索引存儲的是原始字符串 '1', ' 1', '1a'。轉浮點數後均為 1.0，MySQL 無法利用索引有序性，只能全表掃描逐行轉換比較。

為何 BIGINT 加引號不失效？

純數字字符串 '2348993' → 浮點數 2348993.0，與索引值一一對應，順序不變，故可走索引（但仍有 CPU 轉換開銷）。

驗證實驗

SELECT CAST(' 1' AS SIGNED) = 1;   -- 1 (true)
SELECT CAST(' 1a' AS SIGNED) = 1;  -- 1 (true) + Warning
SELECT CAST('1' AS SIGNED) = 1;    -- 1 (true)

浮點數精度陷阱

DOUBLE 只有 53 位有效二進制位（≈15~16 位十進制）。超大整數比較會失真：

SELECT 9223372036854775807 = 9223372036854775808; -- 1 (true!) 精度丟失

最佳實踐：拒絕隱式轉換

1. 代碼規範：所有 SQL 參數綁定時強制類型匹配，ORM 框架配置嚴格模式
2. Code Review 清單：檢查 WHERE/ON/JOIN 條件列類型與參數類型一致性
3. 監控告警：long_query_time + log_queries_not_using_indexes 捕獲隱式轉換慢查詢
4. 數據治理：歷史臟數據清洗，統一字段類型與業務語義

一個引號的缺失，可能拖垮整個數據庫。類型安全，從寫 SQL 那一刻開始。