S08-A20 · 隐式类型转换：索引为什么突然不走了

一条查询 WHERE phone = 13800138000，phone 列是 varchar(20)。上线三个月都没问题，直到某天慢查询报警：它走了全表扫。原因是 MySQL 在"字符串列与数字比较"时会把列转成数字——于是索引失效，而它在前三个月只是"数据量还不够大"。

隐式类型转换是"SQL 优化里最隐蔽的一类"：它不改语义、不报错，只是让索引失效。这类问题的"发现时间"很长：数据量小的时候全扫也很快，于是"漏引号"的 SQL 可能跑半年都没人管——直到表涨到百万级。
而它的触发方式极其自然——一个引号漏了。

1. 三种隐式转换

场景	方向
字符串列 = 数字	列被转成数字（索引失效）
数字列 = 字符串	字符串被转成数字（索引可用）
字符集不同	索引失效（需统一）

第一项是"漏引号"的经典：phone = 13800138000（无引号） 让 MySQL 把 phone 的每一行转成数字后比较第一项的机制值得记：MySQL 在"字符串列与数字比较"时，会把"列"转成数字（而不是把常量转成字符串）——因为"数字比较"优先级更高。于是"转换发生在列上"，索引自然失效。
——于是"扫描全部行"。

第三项还有个"隐式"版本：连接串的 characterEncoding 与列的字符集不同，于是"传进来的字符串"在比较前要转换——同样让索引失效。
第三项在"联表"时出现：两列字符集不同（utf8mb4 与 utf8mb3），比较时无法用索引。

2. 怎么确认"是隐式转换"

手段	得到
`EXPLAIN` 的 `type` 与 `key`	是否全扫（`ALL` / `key=NULL`）
`SHOW WARNINGS`	有时给出"字符集转换"提示
`EXPLAIN FORMAT=JSON`	`attached_condition` 里能看到转换
对比"加引号/不加引号"	计划是否变化

第四项最快：同一条 SQL 只改引号，看计划变不变。若变了，就是隐式转换。第四项的价值在于"它不依赖读文档"：你不需要知道 MySQL 的转换规则，只需要看到"加上引号后计划变了"——这个实验十秒就能做完。

-- 反例：字符串列与数字比较 → 列被转换 → 索引失效
EXPLAIN SELECT * FROM users WHERE phone = 13800138000;
-- type: ALL, key: NULL

-- 正例：带引号 → 索引可用
EXPLAIN SELECT * FROM users WHERE phone = '13800138000';
-- type: ref, key: idx_phone

3. 五种常见触发

触发	例子
数字未加引号	`WHERE code = 1001`（code 是 varchar）
参数类型不匹配	ORM 传 `Long` 给 `varchar` 列
日期字符串格式不同	`'2026-11-10'` vs `'2026/11/10'`
字符集不一致	联表两列 charset 不同
函数包裹列	`WHERE DATE(created_at) = ?`

第二项的排查要点是"看 JDBC 日志里的参数绑定"：setLong(1, 13800138000) 与 setString(1, "13800138000") 会产生完全不同的计划。
第二项在"Java 泛型/包装类型"里很常见：MyBatis 参数是 Long，而列是 varchar，于是 JDBC 用 setLong，MySQL 就做"列转数字"。

第五项（函数包裹）严格说不算"类型转换"，但它与前者同属"让索引失效"的一类——列上套函数，索引必然失效（除非建函数索引）。

"函数包裹列"是同一类问题的另一面，值得单独给一条规则：WHERE 里不要对列做函数运算。

-- 反例：列被函数包裹 → 索引失效（全扫）
SELECT * FROM orders WHERE DATE(created_at) = '2026-11-10';
SELECT * FROM users  WHERE SUBSTR(phone, 1, 3) = '138';

-- 正例：改成"范围"或"前缀匹配"
SELECT * FROM orders WHERE created_at >= '2026-11-10' AND created_at < '2026-11-11';
SELECT * FROM users  WHERE phone LIKE '138%';
-- 前者用上 (created_at) 索引，后者用上 phone 的前缀索引

4. 三种修法

修法	效果
加引号/改参数类型	直接有效
改列类型（同语义）	根治（但需 DDL）
建函数索引	缓解（针对函数包裹）

第一项最便宜：改一行 SQL 或改一个参数类型。第一项的"长期防线"是"类型即契约"：让"列类型"与"参数类型"在代码里显式对应（如 varchar 列对应 String 参数），于是"漏引号"这类问题在类型层面就难以发生。
而它需要"知道是这个问题"——所以检测手段（对比计划）比修法更重要。

第二项要判断"语义是否真是数字"：手机号、编号、邮编都是"字符串"（即使全是数字），因为它们的"数字运算"没有意义，而"前导零"有意义。

// ORM 层：确保参数类型与列类型一致
// 反例：方法参数是 Long，列是 varchar
User findByPhone(Long phone);
// 正例：参数用 String
User findByPhone(String phone);
// 兜底：在 Mapper 上显式 cast/加引号（不推荐长期用）

5. 为什么要"统一字符集"

场景	后果
联表两列字符集不同	索引失效 + 排序不准
应用连接字符集不同	中文乱码或截断
迁移后未统一	部分查询突然变慢

第一项还有个"排序"后果：字符集不同会让排序规则不同，于是"ORDER BY 的结果顺序"可能与预期不一致——而它比"慢"更难发现。
第一项的表现很典型：同一个查询"单独跑很快，联表就慢"。因为联表时"字符集转换"发生在连接列上，于是"用不上索引"。

第三项在"数据库迁移/分库"时出现：新库的默认字符集与老库不同，于是"跨库联表"变慢——而它通常在"数据量上来之后"才被发现。

"计划回归"可以用一条很便宜的基线守住：把关键 SQL 的 EXPLAIN 存成快照，CI 里比对"type/key"是否变化。

// 计划基线的三个断言（每条关键 SQL）
1 type 不退化（ref/range 不能变成 ALL）
2 key 不为 NULL（除非本来就预期全扫）
3 rows 估算数量级不突变（如从 100 变成 1e6）
// 收益：隐式转换/索引被删/统计过期，都会在这里暴露

6. 排错：五种"索引不走"

现象	成因	处理方向
索引存在但 `key=NULL`	隐式转换/函数包裹	对比计划、加引号
单表快、联表慢	字符集不一致	统一字符集
只有部分值慢	参数类型随调用方变化	统一参数类型
加了索引仍全扫	转换发生在列上	改 SQL 或改列
上线后逐渐变慢	数据量增大暴露全扫	同上

第三项很难查：同一个接口，有的调用方传 String、有的传 Long第三项的排查方式是"按调用方分组看延迟"：如果延迟分布呈"两簇"，基本可以断定"参数类型不一致"——而整体均值会把它抹平。
，于是"同一 SQL 有时快有时慢"。

最后一个"迁移"提醒：改列类型（varchar → bigint）看似"根治"，实际会引入新问题——因为"带前导零的值"（00123）会变成 123，于是"等于原来那条记录"的查询再也查不到它。

// 类型变更前的三个检查
1 是否存在前导零（邮编、编号、工号）
2 是否存在非数字值（如 "N/A"、"待定"）
3 是否有长度超限的值（varchar(20) → bigint 会溢出）
// 任一项成立 → 不该改类型，应当改"参数类型/加引号"

7. 边界：什么情况可以不关心

场景	为什么	做法
数字列与数字比较	无转换	不必
小表（万级以内）	全扫也很快	不必
只按主键/唯一键查	转换不影响唯一索引查找	通常不必
已用强类型 ORM 映射	类型一致	不必

最后一条与"评审"有关的边界：隐式转换不会在 code review 里被看出（因为 SQL 与参数类型在不同文件里）。所以它更适合"自动化检查"：抓"数字常量比较字符串列"这类模式，或在 CI 里跑 EXPLAIN 基线。
判断口径一句话：这条 SQL 的列上"会不会发生类型或字符集转换"。会（字符串列对数字、字符集不同），就必须核对计划；不会，索引会正常使用。

8. 自测

三种隐式转换里，哪一种会让索引失效？为什么"漏一个引号"就有这个效果？
最快的确认手段是什么？EXPLAIN 里该看哪两个字段？
为什么"手机号、编号、邮编"应当用字符串类型？前导零在其中起什么作用？
ORM 传 Long 给 varchar 列会发生什么？怎么在映射层避免？
为什么"单表快、联表慢"指向字符集不一致？
判断"是否需要关心"的那个问题是什么？