VARCHAR字段传数字不加引号会导致索引直接失效，因MySQL逐行执行CAST(phone AS SIGNED)，破坏B+树有序性，优化器被迫全表扫描，EXPLAIN显示key: NULL、type: ALL；必须用单引号包裹字符串值并严格保持类型一致。
WHERE里VARCHAR字段传数字不加引号，索引直接失效
这是线上最常踩的坑：字段是VARCHAR，SQL却写成WHERE phone = 13800138000。MySQL会逐行执行CAST(phone AS SIGNED)，B+树索引的有序性被破坏，优化器只能选type: ALL。
常见现象：EXPLAIN显示key: NULL、rows接近全表行数；加引号后毫秒返回，不加引号可能超时。
- MyBatis里误用
${}拼接（如WHERE user_id = ${user_id}），引号被吃掉 - Java后端把手机号当
Long传入，没转成字符串就拼SQL - 前端未校验类型，后端直接拼进SQL
实操建议：
- 所有
VARCHAR/CHAR字段的查询条件，必须显式用单引号包裹值，例如WHERE phone = '13800138000' - MyBatis中一律用
#{}而非${}传参，让框架自动处理引号和转义 - 上线前必须用
EXPLAIN验证关键路径，重点看key是否非NULL、rows是否合理
INT字段传字符串带引号，同样触发隐式转换
反向操作一样危险：id是INT类型，却写成WHERE id = '123'。MySQL会调用CONVERT(id, CHAR)逐行转换——函数作用于列，索引照样不可用。
使用场景：
- Node.js/PHP弱类型驱动自动字符串化ID
- 日志脚本硬编码
WHERE status = '1'（而status是TINYINT）
实操建议：
- 字段类型与查询值类型必须严格一致：
INT就传数字，VARCHAR就传带引号字符串 - 应用层拿到字符串ID时，应在DAO层转成数字再传入，而不是拼进SQL
- 别依赖
CAST(id AS CHAR)兜底——只要函数出现在列上，索引就废了
JOIN时关联字段字符集或排序规则不一致
两张表JOIN，一边是utf8mb4_unicode_ci，另一边是utf8mb4_general_ci，或一张是utf8mb4、另一张是utf8，MySQL无法直接用索引匹配，会降级为嵌套循环+逐行转换。
典型现象：EXPLAIN显示key: NULL，且Extra出现Using where; Using join buffer。
检查方法：
-
SHOW CREATE TABLE t1看CHARSET和COLLATE - 执行
SELECT CHARSET(col), COLLATION(col) FROM t LIMIT 1
修复动作：统一字符集与排序规则，不能只改表结构，还要确认列级定义一致。
EXPLAIN验证必须覆盖所有查询路径
很多团队只在主流程查一次EXPLAIN，但真实业务里存在多条分支路径——比如分页参数为空时走默认值、状态枚举被硬编码成字符串、模糊搜索退化为LIKE '%xxx%'等。
容易被忽略的点：
- ORM自动生成的SQL（如Spring Data JPA的
findByCode）可能因方法签名类型不匹配，悄悄引入隐式转换 - 存储过程或视图内部SQL不受外部参数类型约束，需单独
EXPLAIN - MySQL 9.6.0虽强化了Binlog一致性，但隐式转换导致的索引失效问题并未被绕过——它只管记录，不管执行计划
