WHERE中字符串列与数字字面量比较会导致逐行隐式转换，使索引失效；正确做法是让字面量类型匹配字段类型，如VARCHAR字段用字符串字面量，或显式转换字面量而非字段。
为什么 WHERE 里字符串和数字比较会让索引失效
MySQL 在执行 WHERE column = '123' 时，如果 column 是 INT 类型，会把字符串 '123' 隐式转成整数；但反过来，如果 column 是 VARCHAR，而你写 WHERE column = 123，MySQL 就得把每行字符串都转成数字再比——这就无法用索引的 B+ 树结构快速定位了。
典型现象是：明明字段有索引，EXPLAIN 却显示 type: ALL 或 key: NULL，且 rows 扫描量暴增。
- 隐式转换方向取决于「列类型」和「字面量类型」的优先级，字符串列 vs 数字字面量，总是字符串列被转（逐行）
-
SELECT * FROM users WHERE phone = 13800138000——phone是VARCHAR(11)，这里全表扫描几乎不可避免 - 字符集不一致也会触发隐式转换（比如
utf8mb4列 vsutf8字符串），同样导致索引失效
CAST() 和 CONVERT() 强制转换不一定能救索引
很多人第一反应是“我手动转一下不就得了”，比如写成 WHERE CAST(phone AS UNSIGNED) = 13800138000。但这样反而更糟：函数作用于索引列，MySQL 无法下推索引查找，仍是全表扫描。
真正能走索引的强制转换，只发生在「转换不作用在列上」时，即把字面量转成列的类型：
- ✅ 正确（索引可用）：
WHERE phone = CAST(13800138000 AS CHAR)或WHERE phone = CONVERT(13800138000, CHAR) - ❌ 错误（索引失效）：
WHERE CAST(phone AS CHAR) = '13800138000'—— 函数包裹列名，索引无法使用 - ⚠️ 注意：
CAST(... AS CHAR)默认长度是 1，必须显式指定，如CAST(13800138000 AS CHAR(11))，否则可能截断或隐式补空格引发新问题
SQL 重写的三种有效姿势
比起硬套函数，更可靠的是让查询条件类型与字段类型严格一致。以下方式按推荐度排序：
- 直接用字符串字面量：
WHERE phone = '13800138000'—— 最简单，前提是业务层传参时就保证类型正确（比如 ORM 不自动 cast 数字） - 用
QUOTE()+ 拼接（仅限动态 SQL 场景）：WHERE phone = {QUOTE('13800138000')}，避免应用层拼错引号 - 对已存在的错误 SQL 做兼容兜底：加
AND phone REGEXP '^[0-9]{11}$'等过滤条件虽不能加速索引查找，但可减少无效行处理，配合覆盖索引仍有优化空间
特别注意：MySQL 8.0+ 的函数索引（CREATE INDEX idx_phone_num ON t ((CAST(phone AS UNSIGNED)))）能解决部分场景，但它要求查询里也用完全相同的表达式，且维护成本高，不建议作为首选。
最容易被忽略的字符集和排序规则陷阱
即使类型匹配，WHERE phone = '13800138000' 还是慢？检查 SHOW CREATE TABLE 输出里的 COLLATE。常见坑：
- 字段是
VARCHAR(11) COLLATE utf8mb4_0900_as_cs，而连接字符集是utf8mb4_general_ci，比较时会先转成后者再比，触发隐式转换 - 字段用了
_ci（大小写不敏感）排序规则，但查询值带大小写混合，MySQL 可能放弃索引做全表校对 - 修复方法不是改数据，而是统一连接层的
SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs，或在 SQL 末尾加COLLATE utf8mb4_0900_as_cs
类型对齐只是起点，字符集、排序规则、连接参数三者不一致，照样让前面所有努力白费。
