MySQL 隱式類型轉換導致索引失效實戰：VARCHAR(255) 存數字，查詢慢 46 倍

案例現場

-- 表結構
CREATE TABLE xxx_sources (
    client_id VARCHAR(255),  -- 實際只存數字
    channel   VARCHAR(255),
    KEY idx_client_channel (client_id, channel)
) ENGINE=InnoDB;

-- 慢查詢（11.69s）
SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors
FROM xxx_sources WHERE client_id = 1301
GROUP BY client_id, channel;

-- EXPLAIN 顯示：type=index, key_len=1032, rows=20,207,319（全索引掃描）

根因：隱式類型轉換導致索引不可用

• 列 client_id 定義為 VARCHAR(255)（字符類型）。
• 查詢條件 client_id = 1301 使用 數值字面量。
• MySQL 必須將列值 隱式轉換為數值 才能比較，導致 索引列上有函數操作，優化器放棄 ref 訪問，退化為 index 全掃描。

加引號瞬間優化 46 倍

-- 快查詢（0.25s）
SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors
FROM xxx_sources WHERE client_id = '1301'
GROUP BY client_id, channel;

-- EXPLAIN：type=ref, key_len=258, rows=457,184，Using where; Using index

• key_len 從 1032 降至 258（VARCHAR(255) 字符集 utf8 → 255×3+2=767？實際 258 為 client_id(255) + channel(1) 部分前綴）。
• 訪問類型從 index 變 ref，預估掃描行數從 2000 萬降至 45 萬。
• 耗時 11.69s → 0.25s，提速 46.7 倍。

徹底治本：修正列類型

ALTER TABLE xxx_sources MODIFY client_id INT UNSIGNED NOT NULL;
-- 索引長度進一步縮減至 4 字節，key_len=4，rows 接近精確匹配行數

避坑清單

結語：「贏在起跑線」—— 數據類型選對，索引才能發揮最大效用。一個 VARCHAR(255) 存數字的設計缺陷，導致生產環境查詢慢 46 倍。Schema Review 時，嚴禁「偷懶型」通用字符串定義，按業務語義嚴格選型，是性能優化的零成本最高收益動作。