WHERE id = '123' 走不了索引，因为MySQL将字符串'123'隐式转为数字需逐行计算，违反“索引列独立出现”原则，导致全表扫描（EXPLAIN显示type: ALL、key: NULL）。
WHERE 条件里混用字符串和数字，WHERE id = '123' 为什么走不了索引
MySQL 在比较时会尝试隐式转换，但转换方向取决于字段类型和值类型。当 id 是 INT 类型，而你传入字符串 '123'，MySQL 会把字符串转成数字去比——看起来没问题，但关键在于：**这个转换发生在每一行数据上**，导致无法使用索引的快速定位能力。
本质是优化器判断该条件不满足“索引列独立出现”原则，转为全表扫描。
- 常见错误现象：
EXPLAIN显示type: ALL，key: NULL，哪怕id有索引 - 只对等值查询敏感；范围查询（如
>、BETWEEN）更易失效，因为转换后无法做有序跳转 - 如果字段是
VARCHAR而条件写成数字（WHERE name = 123），MySQL 会把每条name值转成数字再比——同样全表扫，且可能误匹配（'123abc'→123）
CONVERT() 和 CAST() 能绕过隐式转换吗
不能。显式转换只是把隐式过程搬到明面上，依然破坏索引可用性。比如 WHERE CONVERT(id, CHAR) = '123' 或 WHERE CAST(id AS CHAR) = '123'，都是对索引列做了函数操作，MySQL 无法下推索引查找。
- 真正安全的做法是让参数类型严格匹配字段类型：整数字段就传整数，字符串字段就传字符串
- 应用层拼 SQL 时，别用字符串模板拼数字 ID（如
"WHERE id = '" + userId + "'"），改用参数化查询或显式类型转换（如 Java 的PreparedStatement.setInt(1, userId)） - JSON 字段或生成列上用
CAST(json_col->>'$.id' AS UNSIGNED)同样无法走索引——那本来就是表达式，不是原始列
字符集/排序规则不一致也会触发隐式转换
两个字符串字段做 JOIN 或 WHERE 比较时，若字符集不同（如 utf8mb4 vs latin1）或排序规则冲突（如 utf8mb4_0900_as_cs vs utf8mb4_general_ci），MySQL 会选一个“更宽泛”的规则做转换，结果同样是索引失效。
- 典型报错提示：
Using where; Using join buffer (hash join)或Impossible WHERE（极少数情况） - 查表结构用
SHOW CREATE TABLE t，确认COLLATE一致；JOIN 字段建议统一用utf8mb4_unicode_ci（兼顾大小写和性能） - ALTER TABLE 改 collation 会锁表，生产环境慎操作；临时方案可在 WHERE 中加
COLLATE强制对齐，但仍是表达式，不推荐长期用
怎么快速发现这类问题
别等线上慢查爆发。在开发和测试阶段就用 EXPLAIN FORMAT=TRADITIONAL 看执行计划，重点关注 key 是否为空、rows 是否远超预期、Extra 里有没有 Using where 却没走索引。
- 开启慢查询日志，设置
long_query_time = 0.1，配合pt-query-digest扫描高频语句 - 用
SELECT @@sql_mode检查是否含STRICT_TRANS_TABLES——它不会阻止隐式转换，但能避免脏数据写入 - 特别注意 ORM 自动生成的 SQL：Hibernate 的
@Column(columnDefinition = "INT")不代表参数类型自动对齐，JPA 仍可能把 Long 当 Object 传参
