1. 索引失效现象与影响分析
当数据库查询性能突然下降时，经常能在慢查询日志中发现本该走索引的查询变成了全表扫描。上周我处理的一个生产案例中，某核心接口响应时间从200ms骤增至8秒，经排查发现是一个包含status字段的条件查询突然失效。这种索引失效问题在MySQL运维中极为常见，根据我的经验统计，约60%的SQL性能问题都与索引使用不当有关。
索引失效最直接的后果就是查询效率呈数量级下降。一个简单的用户表查询，在走索引时可能只需扫描10行数据，而全表扫描则要遍历500万行。更严重的是，大量全表扫描会迅速耗尽数据库缓冲池，引发连锁反应导致整个系统性能下降。我曾见过一个索引失效问题导致整个数据库CPU持续100%运行16小时，最终不得不紧急回滚版本。
2. 常见失效原因深度解析
2.1 隐式类型转换陷阱
当字段类型与查询条件类型不一致时，MySQL会进行隐式类型转换导致索引失效。例如：
sql复制-- user_id是varchar类型但用了数字查询
SELECT * FROM users WHERE user_id = 10086;
-- create_time是datetime但用了字符串比较
SELECT * FROM orders WHERE create_time > '2023-01-01';
这种问题在PHP等弱类型语言开发的系统中尤为常见。解决方案包括：
- 使用CAST或CONVERT函数显式转换
- 修改应用代码确保类型一致
- 最根本的是在设计阶段统一字段类型
注意：datetime与timestamp的混用也会导致隐式转换，虽然两者都表示时间但存储机制完全不同
2.2 最左前缀原则违反
复合索引(a,b,c)的实际存储结构可以理解为将三个字段值拼接后的有序字符串。以下情况会导致索引失效：
sql复制-- 缺失最左字段a
SELECT * FROM table WHERE b = 2 AND c = 3;
-- 跳过了中间字段b
SELECT * FROM table WHERE a = 1 AND c = 3;
我建议的复合索引设计原则：
- 区分度高的字段靠左
- 等值查询字段优先于范围查询字段
- 常用查询条件尽量覆盖
2.3 索引列参与运算
在索引字段上使用函数或运算会使索引失效：
sql复制-- 错误示例
SELECT * FROM users WHERE YEAR(create_time) = 2023;
SELECT * FROM products WHERE price + 100 > 500;
优化方案：
- 对create_time使用范围查询
- 预先计算好price + 100的值存储
- 使用生成列(functional index)
2.4 OR条件使用不当
当OR条件中包含非索引列时会导致全表扫描：
sql复制-- status有索引但description没有
SELECT * FROM articles
WHERE status = 'published' OR description LIKE '%重要%';
解决方案：
- 使用UNION ALL替代OR
- 为description添加全文索引
- 拆分为两个查询在应用层合并
3. 高级场景与特殊案例
3.1 IS NULL与IS NOT NULL的索引使用
在MySQL中，IS NULL条件可以使用索引，但IS NOT NULL通常不会走索引。这是因为NULL值在索引中被特殊存储：
sql复制-- 可能使用索引
SELECT * FROM users WHERE phone IS NULL;
-- 通常不会走索引
SELECT * FROM users WHERE phone IS NOT NULL;
优化技巧：
- 考虑用默认值替代NULL
- 对必须使用IS NOT NULL的查询单独建立索引
3.2 索引合并(Index Merge)的局限性
MySQL支持通过index_merge优化器策略合并多个索引扫描，但有以下限制：
- 只适用于OR条件的AND组合
- 各索引必须返回有序rowid
- 合并成本可能高于全表扫描
通过EXPLAIN看到type=index_merge时需要特别注意性能：
sql复制EXPLAIN SELECT * FROM users
WHERE username = 'admin' OR email = 'admin@example.com';
3.3 字符集与排序规则影响
当关联查询的字段字符集或排序规则不一致时，索引可能失效：
sql复制-- utf8与utf8mb4混用
SELECT * FROM t1 JOIN t2 ON t1.name = t2.name
WHERE t1.name COLLATE utf8_general_ci = t2.name COLLATE utf8mb4_general_ci;
最佳实践：
- 统一使用utf8mb4字符集
- 显式指定COLLATE子句
- 定期检查schema中的字符集一致性
4. 诊断与排查实战指南
4.1 EXPLAIN执行计划解读要点
分析EXPLAIN结果时重点关注：
| 列名 | 关键值 | 含义 |
|---|---|---|
| type | const/ref/range | 理想情况 |
| index/all | 需要优化 | |
| key | NULL | 索引未使用 |
| rows | 数值过大 | 扫描行数过多 |
| Extra | Using filesort | 需要排序优化 |
| Using temporary | 创建临时表 |
4.2 性能诊断工具链
我的常用排查工具组合：
- 慢查询日志分析
sql复制-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
- Performance Schema监控
sql复制-- 查看等待事件
SELECT * FROM performance_schema.events_waits_current;
- SHOW PROFILE分析
sql复制SET profiling = 1;
-- 执行查询
SHOW PROFILE CPU, BLOCK IO FOR QUERY 1;
4.3 索引优化器提示
当优化器选择不当时可强制使用索引：
sql复制-- 强制使用特定索引
SELECT * FROM users FORCE INDEX(idx_username)
WHERE username = 'test';
-- 忽略索引
SELECT * FROM users IGNORE INDEX(idx_status)
WHERE status = 1 AND create_time > '2023-01-01';
5. 预防措施与最佳实践
5.1 索引设计检查清单
创建新索引时我的自检清单：
- 字段基数(Cardinality)是否足够高？
- 是否遵循最左前缀原则？
- 是否避免在索引列上运算？
- 字段类型是否与查询条件匹配？
- 是否考虑了查询频率和数据更新频率的平衡？
5.2 定期索引健康检查
建议每月执行的索引维护脚本：
sql复制-- 查找冗余索引
SELECT * FROM sys.schema_redundant_indexes;
-- 查找未使用索引
SELECT * FROM sys.schema_unused_indexes;
-- 更新统计信息
ANALYZE TABLE important_table;
5.3 索引监控报警配置
在生产环境配置的监控项：
- 索引使用率监控
- 索引碎片率超过30%报警
- 全表扫描查询突增报警
- 排序操作临时表创建监控
6. 真实案例复盘
去年处理的一个典型案例：某电商平台促销期间订单查询超时。经分析发现：
- 问题SQL：
sql复制SELECT * FROM orders
WHERE DATE(create_time) = '2023-11-11'
AND status IN (1,2,5)
ORDER BY amount DESC
LIMIT 100;
- 根本原因：
- DATE()函数导致create_time索引失效
- status的IN查询效率低下
- 排序字段无索引
- 优化方案：
sql复制-- 新建复合索引
ALTER TABLE orders ADD INDEX idx_status_ctime_amount(status, create_time, amount);
-- 改写查询
SELECT * FROM orders
WHERE create_time >= '2023-11-11 00:00:00'
AND create_time < '2023-11-12 00:00:00'
AND status IN (1,2,5)
ORDER BY amount DESC
LIMIT 100;
优化后查询时间从4.7秒降至23毫秒。这个案例充分展示了正确理解索引工作原理的重要性。