MySQL 索引失效现场：一条 SQL 让生产库跪了
MySQL 索引失效现场：一条 SQL 让生产库跪了
上周五下午，正在摸鱼的我突然收到生产库 CPU 飙高的报警。查了一下，发现是一条看起来人畜无害的 SQL 把整个数据库拖垮了。事后复盘，问题出在索引失效上。今天把这个坑记录下来，希望能帮到正在看文章的你。
事故现场：那个看似正常的 SQL
问题 SQL 大概是这样的（简化版）：
SELECT*FROMordersWHEREDATE_FORMAT(create_time,'%Y-%m')='2026-02'ANDstatus='pending'ANDuser_idLIKE'123%';这条 SQL 看起来没什么问题吧？WHERE 条件都有，应该能走索引啊。
但实际执行计划显示：全表扫描。
踩坑分析：三个让索引失效的操作
1. 函数运算让索引失效
第一个坑是DATE_FORMAT(create_time, '%Y-%m')。
索引列上做任何函数运算，都会导致索引失效。
我原意是按月份查询，所以对 create_time 做了日期格式化。但 MySQL 在执行时会先对每一行调用函数，再比较结果。这相当于给每行数据做了"预处理"，索引就派不上用场了。
正确做法：直接用范围查询
SELECT*FROMordersWHEREcreate_time>='2026-02-01'ANDcreate_time<'2026-03-01'ANDstatus='pending'ANDuser_idLIKE'123%';2. LIKE 开头是通配符
第二个坑是user_id LIKE '123%'。
如果你用过 LIKE，应该知道'%abc'肯定不走索引，但'abc%'理论上可以走索引。
但这里有个隐藏问题：如果 user_id 是字符串类型，而 status 字段在索引中排在 user_id 前面，MySQL 可能选择不走索引。
因为 MySQL 的索引是按照索引列顺序组织的，如果前面的列（status）不是确定的值（是范围查询），后面的列就很难使用索引。
解决方案：根据实际情况调整索引顺序，或者用覆盖索引。
3. 字段类型不匹配
第三个坑可能很多人没注意到：user_id 的类型。
如果 user_id 在数据库是 VARCHAR 类型，但传入的 ‘123%’ 被当作字符串处理，这没问题。但如果是 INT 类型，LIKE 操作就会触发隐式类型转换：
-- 如果 user_id 是 BIGINTWHEREuser_idLIKE'123%'-- 实际上会变成WHERECAST(user_idASCHAR)LIKE'123%'类型转换 = 索引失效。
解决方案：这样写 SQL 才能用到索引
经过排查，我最终把 SQL 改成了这样：
SELECT*FROMordersWHEREcreate_time>='2026-02-01 00:00:00'ANDcreate_time<'2026-03-01 00:00:00'ANDstatus='pending'ANDuser_id>='123'ANDuser_id<'124';当然，最稳妥的方式是看执行计划：
EXPLAINSELECT*FROMorders...重点关注这几个字段：
- type：最好的是 const，次之 ref，最差是 ALL（全表扫描）
- key：实际用的索引
- rows：扫描的行数（越大说明越慢）
写在最后
这次事故让我深刻体会到：SQL 优化真的不是背背八股文就够的。纸上谈兵和实战差距太大了。
几点血泪教训：
- 线上环境务必打开慢查询日志，出了问题有据可查
- ** EXPLAIN 是最好的老师**，不确定的时候先跑一下
- 索引最左前缀原则要牢记：范围查询后的列不走索引
如果你也写过类似的"看起来没问题"的 SQL，欢迎评论区晒一晒，相互避坑。