varchar字段传数字不加引号会导致隐式类型转换，使B+树索引有序性被破坏，优化器放弃索引而全表扫描，EXPLAIN显示type=ALL、key=NULL。
varchar字段传数字不加引号，索引直接失效
MySQL在执行查询时，如果WHERE条件中对varchar类型字段传入未加引号的数字（比如user_id = 12345），会触发隐式类型转换：把字符串字段强制转成数字再比对。这个过程等价于在索引列上套了CAST()函数，破坏B+树索引的有序性，优化器只能放弃走索引，退化为全表扫描。
常见错误现象：
-
EXPLAIN显示type=ALL，key=NULL - 相同SQL，加引号响应毫秒级，不加引号查几秒甚至超时
- MyBatis里误用
${}拼接参数（如WHERE user_id = ${user_id}），导致引号丢失
实操建议：
- 所有
varchar/char字段的查询条件，必须显式使用单引号包裹值，例如WHERE user_id = '12345' - MyBatis中一律用
#{}而非${}传参，让框架自动处理引号和转义 - 上线前用
EXPLAIN验证关键查询，重点检查key和rows字段
int字段传字符串带引号，同样触发隐式转换
反过来也成立：索引字段是INT类型，但查询时传了字符串（如id = '123'），MySQL会把整型列转成字符串再比较。虽然看起来只是“多包一层”，但实际执行计划中仍会调用CONVERT()，导致索引失效。
使用场景：
- 前端传参未校验类型，后端直接拼SQL或用弱类型ORM（如部分PHP/Node.js驱动）
- 日志分析脚本中硬编码SQL，写成
WHERE status = '1'而字段是TINYINT
实操建议：
- 字段类型与查询值类型严格一致——
INT就传数字，VARCHAR就传带引号字符串 - 避免在应用层做“字符串→数字”预处理后再拼SQL；应由数据库驱动或ORM保障类型传递准确
- 用
SHOW CREATE TABLE确认字段真实类型，别只看业务文档或Java实体类注解
JOIN关联字段字符集或排序规则不一致
两张表JOIN时，若关联字段字符集不同（如一张是utf8mb4，另一张是utf8）或排序规则不一致（如utf8mb4_unicode_ci vs utf8mb4_general_ci），MySQL无法直接用索引做快速匹配，会降级为嵌套循环+临时转换，严重拖慢性能。
容易踩的坑：
- 历史表迁移未统一字符集，新旧表JOIN时突然变慢
- Docker部署中MySQL配置文件未显式指定
character_set_server，依赖镜像默认值 - 建表语句漏写
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
实操建议：
- 执行
SHOW FULL COLUMNS FROM table_name，核对Collation列是否完全一致 - ALTER TABLE统一字符集：
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 连接字符串中显式指定
characterEncoding=utf8mb4，避免JDBC驱动自动降级
复合索引中某列发生隐式转换，整条索引失效
即使只有一列出问题，整个复合索引也可能作废。例如联合索引(status, create_time, user_id)，如果user_id是VARCHAR但查询写了WHERE status = 1 AND user_id = 12345，优化器发现user_id列要转换，就会放弃整条索引，而不是只跳过最后一列。
为什么这样做：
- MySQL的最左前缀匹配依赖每列值的原始存储格式，一旦某列被函数/转换包裹，后续列的有序性无法保证
- 优化器不会“局部启用”索引，只有全路径可用才走索引
实操建议：
- 对复合索引每一列都做类型校验，尤其注意中间或末尾的字符串字段
- 用
EXPLAIN FORMAT=JSON查看used_key_parts，确认哪些列真正被索引覆盖 - 开发阶段在测试库开启
sql_mode=STRICT_TRANS_TABLES，让隐式转换直接报错而非静默失败
最麻烦的不是查不到索引，而是它“看起来能用”——EXPLAIN显示key有值，但rows接近总行数，说明索引被部分使用却效率极低。这种半失效状态最难排查，务必在数据量上来之前就压测并固定参数类型。
