在MySQL InnoDB 5.7数据库中，索引如同图书馆的目录系统，能帮助数据库引擎快速定位目标数据。但实际开发中常常遇到索引失效的诡异现象：明明建立了索引，查询却进行全表扫描，响应时间从毫秒级骤降到秒级。本文将揭示索引失效的底层原理，解析6个高频失效场景，并提供可直接落地的优化方案。
一、索引失效的核心原理
1.1 B+树索引的工作机制
InnoDB采用B+树结构存储索引数据，其特性包括：
多层级平衡树结构
叶子节点存储完整数据记录
非叶子节点仅存储键值和指针
数据按索引键值有序排列
1.2 索引生效的关键条件
索引有效需要满足最左前缀匹配原则：
SELECT FROM users WHERE name LIKE '张%' AND age=30
当建立(name,age)联合索引时，查询会先匹配name前缀，再过滤age值，实现高效检索。
二、六大高频索引失效场景
2.1 隐式类型转换（死亡率90%）
场景示例：
SELECT FROM orders WHERE user_id = '10086' user_id是INT类型
失效原因：字符串与数字类型比较时，MySQL会进行隐式转换，导致索引失效。
★ 修复方案：确保查询条件与索引列类型完全一致，必要时使用CAST()显式转换。
2.2 索引列参与运算（死亡率85%）
错误示范：
SELECT FROM products WHERE YEAR(create_time) = 2023
优化方案：
SELECT FROM products
WHERE create_time BETWEEN '2023到01-01' AND '2023到12-31'
2.3 左模糊查询（死亡率75%）
问题语句：
SELECT FROM articles WHERE content LIKE '%数据库%'
★ 解决方案：
1. 使用覆盖索引：CREATE INDEX idx_content ON articles(content)
2. 转用全文检索：MATCH(content) AGAINST('数据库')
2.4 OR条件使用不当（死亡率60%）
错误案例：
SELECT FROM employees
WHERE department_id = 5 OR salary > 10000
优化技巧：将OR拆分为UNION查询：
(SELECT FROM employees WHERE department_id = 5)
UNION
(SELECT FROM employees WHERE salary > 10000)
2.5 统计信息不准确（死亡率50%）
当表数据量发生剧烈变化（如大范围DELETE）后，可能出现：
索引基数(cardinality)统计偏差
优化器错误选择全表扫描
★ 修复命令：
ANALYZE TABLE employees;
2.6 索引选择性过低（死亡率40%）
典型场景：在性别字段（男/女）建立独立索引
优化方案：改用联合索引：
ALTER TABLE users ADD INDEX idx_gender_city(gender, city);
三、索引优化四步检查法
- EXPLAIN诊断：查看type列是否为index/range
- 索引覆盖检查：避免出现”Using filesort”
- 数据分布分析：执行
SHOW INDEX FROM table - 强制索引测试：使用
FORCE INDEX验证效果
四、最佳实践总结
- 联合索引字段顺序遵循高频查询在前、高选择性在后原则
- 避免在WHERE子句中对索引列进行函数处理或计算
- UPDATE/DELETE语句同样需要索引优化
- 定期使用
OPTIMIZE TABLE整理索引碎片
通过理解B+树索引的工作原理，规避上述六大失效场景，可以让MySQL查询性能提升10倍以上。建议开发者建立索引使用检查清单，在编写SQL时主动预防索引失效问题。
正文完
