1. MySQL索引失效的底层原理剖析
索引失效的本质原因可以归结为两点：破坏了B+树索引的有序性，或者优化器判断全表扫描的成本更低。要深入理解这个问题，我们需要从MySQL索引的底层实现说起。
1.1 B+树索引的工作原理
MySQL的InnoDB存储引擎默认使用B+树作为索引结构。B+树具有以下关键特性：
- 所有数据都存储在叶子节点，且叶子节点之间通过指针相连形成有序链表
- 非叶子节点只存储键值和子节点指针，不存储实际数据
- 树的高度通常维持在3-4层，保证千万级数据也能在3-4次IO内定位到记录
当执行等值查询（如WHERE id=100）时，MySQL会从根节点开始：
- 比较查询值与节点中的键值范围，确定下一层子节点
- 重复这个过程直到叶子节点
- 在叶子节点中通过二分查找定位具体记录
这种查找方式的效率依赖于索引键的有序性。任何破坏这种有序性的操作都会导致索引失效。
1.2 优化器的成本计算逻辑
MySQL优化器在选择执行计划时，会基于成本模型进行估算，主要考虑：
- IO成本：读取数据页的代价
- CPU成本：处理数据的代价
- 内存成本：使用临时表或排序的代价
当优化器判断使用索引的成本高于全表扫描时（通常发生在预计要访问超过30%的数据行时），就会放弃使用索引。这就是为什么某些情况下即使技术上可以使用索引，MySQL也会选择全表扫描。
2. 索引失效的九大场景深度解析
2.1 OR条件导致的索引失效
OR条件导致索引失效的根本原因是"离散条件合并"问题。假设我们有以下查询：
sql复制SELECT * FROM orders WHERE user_id = 100 OR amount > 1000;
即使user_id和amount都有索引，MySQL也需要：
- 使用user_id索引查找user_id=100的记录
- 使用amount索引查找amount>1000的记录
- 对两个结果集进行去重合并
这个过程的成本可能比直接全表扫描更高，特别是当OR条件中有一个字段没有索引时，MySQL只能选择全表扫描。
优化方案：
- 将OR改写为UNION：
sql复制SELECT * FROM orders WHERE user_id = 100
UNION
SELECT * FROM orders WHERE amount > 1000;
- 确保OR条件中的所有字段都有合适的索引
- 考虑使用复合索引覆盖多个OR条件
2.2 隐式类型转换导致索引失效
当查询条件的类型与列定义类型不匹配时，MySQL会进行隐式类型转换。这种转换相当于在列上使用了函数，破坏了索引的有序性。
常见陷阱：
- 字符串列与数字比较：
WHERE phone = 13800138000 - 日期列与字符串比较：
WHERE create_time = '2023-01-01' - ENUM列与数字比较：
WHERE status = 1（status是ENUM类型）
优化方案：
- 严格匹配列的数据类型
- 使用EXPLAIN检查是否出现"type_conversion"警告
- 对于日期时间列，使用标准的格式：
WHERE create_time = '2023-01-01 00:00:00'
2.3 LIKE通配符导致索引失效
LIKE条件是否使用索引取决于通配符的位置：
LIKE 'abc%'：可以使用索引（前缀匹配）LIKE '%abc'或LIKE '%abc%'：无法使用索引
特殊情况：
对于较短的固定模式（如LIKE 'abc_def'），某些情况下MySQL可能会使用索引下推优化。
优化方案：
- 尽量避免前导通配符
- 考虑使用全文索引（FULLTEXT）替代LIKE
- 对于后缀搜索需求，可以存储反转后的字符串并建立索引：
sql复制ALTER TABLE users ADD COLUMN name_reverse VARCHAR(100);
UPDATE users SET name_reverse = REVERSE(name);
CREATE INDEX idx_name_reverse ON users(name_reverse);
-- 查询以"son"结尾的名字
SELECT * FROM users WHERE name_reverse LIKE 'nos%';
2.4 联合索引的最左前缀原则
联合索引(a,b,c)的B+树是按照a、b、c的顺序构建的。查询必须包含最左列才能利用索引的有序性。
有效使用场景：
WHERE a=1WHERE a=1 AND b=2WHERE a=1 AND b=2 AND c=3
失效场景：
WHERE b=2（缺少最左列a）WHERE a=1 AND c=3（跳过中间列b）
优化方案：
- 根据业务查询模式设计合理的联合索引顺序
- 使用索引覆盖扫描避免回表：
sql复制-- 假设有联合索引(a,b,c)
SELECT a,b,c FROM table WHERE a=1 AND b=2; -- 不需要回表
2.5 索引列使用函数导致失效
在索引列上使用函数（如DATE()、SUBSTRING()等）会导致索引失效，因为索引存储的是原始值而非函数计算结果。
常见问题函数：
- 日期函数：
DATE(),YEAR(),MONTH() - 字符串函数：
SUBSTRING(),UPPER(),LOWER() - 数学函数：
ABS(),FLOOR(),CEILING()
优化方案：
- 改写为范围查询：
sql复制-- 原查询（索引失效）
SELECT * FROM orders WHERE DATE(create_time) = '2023-01-01';
-- 优化后（索引生效）
SELECT * FROM orders
WHERE create_time >= '2023-01-01 00:00:00'
AND create_time < '2023-01-02 00:00:00';
- 使用计算列+索引：
sql复制ALTER TABLE orders ADD COLUMN create_date DATE AS (DATE(create_time)) STORED;
CREATE INDEX idx_create_date ON orders(create_date);
2.6 索引列进行算术运算导致失效
在索引列上进行加减乘除运算（如id+1=10）会导致索引失效，原理与函数类似。
优化方案：
- 将运算移到等号另一边：
sql复制-- 原查询（索引失效）
SELECT * FROM users WHERE id + 1 = 10;
-- 优化后（索引生效）
SELECT * FROM users WHERE id = 9;
- 对于复杂计算，考虑使用计算列
2.7 使用!=、<>、NOT IN导致失效
这些否定条件通常会导致优化器选择全表扫描，因为：
- 结果集通常很大（排除少量数据）
- 使用索引需要多次随机IO，成本较高
优化方案：
- 对于小表或高选择性查询，可以尝试使用索引
- 考虑改写为等值查询：
sql复制-- 原查询
SELECT * FROM users WHERE status NOT IN (1,2);
-- 可能优化为
SELECT * FROM users WHERE status = 0 OR status = 3 OR status = 4;
- 使用LEFT JOIN排除：
sql复制SELECT a.* FROM table_a a
LEFT JOIN table_b b ON a.id = b.id AND b.status = 'deleted'
WHERE b.id IS NULL;
2.8 IS NULL/IS NOT NULL导致失效
NULL值在索引中的处理比较特殊：
- IS NULL可以使用索引（B+树会记录NULL值位置）
- IS NOT NULL通常会失效，因为要返回大部分数据
优化方案：
- 对于允许NULL的列，考虑设置合理的默认值
- 对于必须查询NULL的情况，可以尝试使用覆盖索引
2.9 连接查询编码不一致导致失效
当连接字段的字符集或排序规则不一致时，MySQL需要进行隐式转换，导致索引失效。
常见问题场景：
- utf8与utf8mb4混用
- 不同排序规则（如utf8_general_ci与utf8_bin）
优化方案：
- 统一数据库的字符集和排序规则
- 在表设计时就考虑编码一致性
- 必要时使用CONVERT函数显式转换：
sql复制SELECT * FROM a JOIN b ON a.name = CONVERT(b.name USING utf8mb4);
3. 索引优化实战技巧
3.1 如何判断索引是否失效
使用EXPLAIN命令分析查询执行计划，重点关注：
- type列：最好达到ref或range级别
- key列：显示实际使用的索引
- Extra列：避免出现"Using filesort"或"Using temporary"
示例分析：
sql复制EXPLAIN SELECT * FROM users WHERE name LIKE '%张%';
如果type=ALL且key=NULL，说明是全表扫描，索引失效。
3.2 索引设计的最佳实践
-
选择性原则：选择高选择性的列建立索引（如ID、手机号等）
- 选择性 = 不同值的数量 / 总行数
- 一般选择性>0.1的列适合建索引
-
覆盖索引：让索引包含查询所需的所有字段
sql复制-- 有索引(name, age) SELECT name, age FROM users WHERE name LIKE '张%'; -- 覆盖索引 -
索引合并：合理使用联合索引减少索引数量
- 遵循最左前缀原则
- 将等值查询列放在联合索引左侧
-
前缀索引：对于长字符串列，可以使用前缀索引
sql复制ALTER TABLE articles ADD INDEX idx_title(title(20));
3.3 索引维护与监控
-
定期分析索引使用情况：
sql复制SELECT * FROM sys.schema_unused_indexes; SELECT * FROM sys.schema_redundant_indexes; -
索引统计信息更新：
sql复制ANALYZE TABLE users; -
监控索引效率：
sql复制-- 查看索引的区分度 SELECT index_name, count(*) AS index_rows, round(count(*) * 100 / (SELECT count(*) FROM users), 2) AS index_selectivity FROM users FORCE INDEX(primary) GROUP BY index_name;
4. 真实案例分析与解决方案
4.1 电商平台订单查询优化
问题描述：
订单表有500万数据，查询WHERE status=1 AND create_time > '2023-01-01'很慢。
分析过程：
- 现有索引：
(status)和(create_time) - EXPLAIN显示使用了
status索引，但扫描行数仍有200万 - 因为status=1的订单占比40%，索引效率低
解决方案：
- 创建联合索引
(status, create_time) - 改写查询为
WHERE status=1 AND create_time > '2023-01-01' LIMIT 1000 - 添加
ORDER BY create_time DESC利用索引排序
4.2 社交平台用户搜索优化
问题描述：
用户表需要支持多种条件组合查询，如：
sql复制WHERE (age BETWEEN 20 AND 30)
AND (gender = 'F')
AND (city LIKE '%北京%')
优化方案：
- 创建适应性强的联合索引
(gender, age, city(10)) - 对于城市搜索，使用前缀索引
- 考虑使用Elasticsearch等专业搜索工具处理复杂搜索需求
4.3 日志分析系统查询优化
问题描述：
日志表每天新增百万数据，需要查询特定时间段和错误级别的记录：
sql复制WHERE log_time BETWEEN '2023-01-01' AND '2023-01-02'
AND level = 'ERROR'
优化方案：
- 按时间范围分区：
PARTITION BY RANGE (TO_DAYS(log_time)) - 创建本地索引
(level) - 查询时只扫描相关分区
5. 高级索引策略与未来趋势
5.1 函数索引（MySQL 8.0+）
MySQL 8.0支持函数索引，可以解决部分索引失效问题：
sql复制-- 创建函数索引
CREATE INDEX idx_name_lower ON users((LOWER(name)));
-- 查询使用索引
SELECT * FROM users WHERE LOWER(name) = '张三';
5.2 降序索引优化
MySQL 8.0支持降序索引，优化特定排序场景：
sql复制-- 创建降序索引
CREATE INDEX idx_score_desc ON students(score DESC);
-- 高效处理降序查询
SELECT * FROM students ORDER BY score DESC LIMIT 100;
5.3 不可见索引
用于测试索引删除的影响：
sql复制-- 将索引设置为不可见
ALTER TABLE users ALTER INDEX idx_name INVISIBLE;
-- 测试查询性能后再决定是否删除
5.4 索引跳跃扫描
MySQL 8.0引入的优化，可以在某些情况下跳过联合索引的前导列：
sql复制-- 有索引(gender, age)
-- 8.0+可能使用索引，即使查询没有gender条件
SELECT * FROM users WHERE age > 20;
在实际工作中，我发现索引优化是一个需要持续关注和调整的过程。随着数据量的增长和查询模式的变化，原先有效的索引可能会变得低效。定期使用EXPLAIN分析慢查询，结合业务特点调整索引策略，才能保持数据库的高性能。