MySQL索引失效五大场景与优化实战

1. MySQL索引失效的五大陷阱与实战解决方案

作为经历过三次线上数据库性能灾难的老兵，我深刻体会到索引失效带来的痛苦——半夜被报警叫醒、业务高峰期系统卡顿、用户投诉如潮水般涌来。经过这些惨痛教训，我总结出MySQL索引最致命的五个失效场景，每个都配有真实案例和解决方案。这些经验能帮你避开90%的索引坑，建议开发团队纳入Code Review checklist。

2. 联合索引的左前缀陷阱：顺序决定生死

2.1 问题复现：一个索引引发的全表扫描

去年双十一大促前，我们的用户查询接口突然响应时间从200ms飙升到8秒。检查发现核心SQL是：

sql复制SELECT * FROM user_address 
WHERE city_code = '021' AND district_code = '0101';

虽然表上有联合索引idx_area(province_code, city_code, district_code)，但EXPLAIN显示type=ALL（全表扫描）。当时在线用户20万+，这个查询每分钟执行3万次，数据库CPU直接飙到100%。

2.2 原理剖析：B+树的排列规则

联合索引的存储结构就像电话簿：

• 先按省份拼音排序
• 同省份再按城市排序
• 同城市最后按区县排序

当查询条件缺少province_code时，就像让你在无序堆叠的电话簿中找"所有叫张三的人"——除了逐页翻查别无他法。这就是最左前缀原则的本质。

2.3 解决方案与避坑指南

方案一：补齐前缀条件（推荐）

sql复制-- 增加province_code条件后，索引立即生效
SELECT * FROM user_address 
WHERE province_code = '31' 
  AND city_code = '021' 
  AND district_code = '0101';

方案二：调整索引顺序（需评估查询模式）

sql复制-- 如果80%查询都只用city_code和district_code
ALTER TABLE user_address 
DROP INDEX idx_area,
ADD INDEX idx_city_district(city_code, district_code);

方案三：使用索引覆盖（减少回表）

sql复制-- 只查询索引包含的字段
SELECT province_code, city_code, district_code 
FROM user_address 
WHERE city_code = '021';

避坑提示：设计联合索引时，把区分度高的字段放左边。可通过`SELE