根本原因是隐式转换破坏b+树索引有序性，导致全表扫描；正确做法是严格匹配字段与查询值类型，如varchar字段必须用单引号传字符串、int字段直接传数字，并禁用${}拼接和列上函数。
隐式类型转换导致索引失效，根本原因不是“MySQL不聪明”，而是它被迫在每行上做类型转换，破坏了B+树索引的有序查找能力。只要让查询值类型严格匹配字段类型，90%以上的问题当场消失。
WHERE里VARCHAR字段传数字不加引号
这是最常见也最危险的写法：字段是VARCHAR，但SQL里写成WHERE phone = 13800138000。MySQL会把每行phone字符串转成数字再比——等价于给索引列套了CAST()，优化器直接放弃索引。
- 典型现象：
EXPLAIN显示type: ALL、key: NULL、rows等于全表行数 - MyBatis中尤其高发：误用
${}拼接参数（如WHERE user_id = ${user_id}），引号被吃掉 - 正确做法：一律用
WHERE phone = '13800138000'，单引号不可省 - 上线前必须用
EXPLAIN验证，别信“看起来差不多”
WHERE里INT字段传字符串带引号
反向操作同样致命：id是INT类型，却写成WHERE id = '123'。MySQL会把整型列逐行转成字符串比较，依然触发隐式转换，索引照样失效。
- 常见于前端传参未校验、Node.js/PHP弱类型驱动自动字符串化ID
- 正确做法：保持类型原生，
WHERE id = 123；如果应用层只能拿到字符串，应在DAO层转成数字再传入，而不是拼进SQL - 别依赖
CAST(id AS CHAR)来“兜底”——函数作用于列，索引仍不可用
JOIN时关联字段字符集或排序规则不一致
两张表JOIN，一边是utf8mb4_unicode_ci，另一边是utf8mb4_general_ci，或者一张是utf8mb4、另一张是utf8，MySQL无法直接用索引做等值匹配，会退化为嵌套循环+逐行转换。
- 检查方式：
SHOW CREATE TABLE table_name，对比COLLATE和CHARSET - 修复动作：统一字符集与排序规则，例如执行
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 注意：修改字符集可能锁表，生产环境需评估窗口期
强制转换函数用错位置
很多人想“手动控制转换”，结果把CAST()或CONVERT()套在列名上，比如WHERE CAST(phone AS UNSIGNED) = 13800138000——这等于主动废掉索引。
- 能走索引的唯一合法写法是转换字面量：
WHERE phone = CAST(13800138000 AS CHAR(11)) -
CAST(... AS CHAR)默认长度是1，必须显式指定长度，否则截断或补空格引发新问题 - MySQL 8.0+的函数索引（如
CREATE INDEX idx_phone_num ON t ((CAST(phone AS UNSIGNED)))）理论上可行，但要求查询表达式完全一致，且维护成本高，不建议作为首选方案
真正难的不是写出正确的SQL，而是在ORM、日志脚本、动态拼接、跨服务调用这些场景里，始终守住“字段类型=查询值类型”这一条线。类型不一致的瞬间，索引就从加速器变成了摆设。
