MySQL 索引失效全解析与优化指南

在关系型数据库里，索引是加速查询的核心武器。索引失效不是“索引坏了”，而是优化器没有或不能利用索引的有序性来快速定位数据，最终选择了全表扫描或更慢的执行计划。

理解索引失效的底层原理与常见场景，并掌握对应的修复方法，能显著提升 SQL 性能。

---

一、索引失效的底层逻辑（本质与常见触发原因）

在 B+ 树索引结构中，索引之所以能加速查询，是因为索引键值在叶子节点中是有序排列的。优化器之所以“走索引”，本质是利用这种有序性做快速定位或范围扫描。一旦查询条件破坏了索引的顺序性或匹配能力，索引就无法发挥作用。

主要失效原因包括：

1. 排序链断裂

   • 当查询条件无法沿索引顺序匹配时，B+ 树无法快速定位数据区间。

   • 例如联合索引 (city, age, username)，查询只用 age 或 username，起始节点无法定位。

2. 值域跳跃

   • 范围查询或函数运算改变索引列的值域，索引无法连续扫描。

   • 例如 YEAR(create_time) = 2025，索引存储的是完整时间戳，无法匹配计算后的年份。

3. 二次计算

   • 查询使用函数或表达式处理索引列，如 CAST()、LOWER()、+1 等，会破坏索引原始值匹配。

4. 成本误判

   • 优化器基于统计信息估算成本，当索引选择性低或数据分布变化时，可能放弃索引。

   • 例如性别字段索引，男女比例 50:50，优化器可能认为全表扫描更快。

---

二、20 种典型索引失效场景

1. 违反最左前缀原则

业务表：user (id, city, age, username)

联合索引：(city, age, username)

-- ❌ 错误示例：缺失最左前缀 city，索引失效
SELECT * FROM user WHERE age = 25 AND username = 'Tom';-- ✅ 正确示例：使用最左前缀 city
SELECT * FROM user WHERE city = 'Beijing' AND age = 25;

原因分析：

B+ 树索引按 (city → age → username) 顺序存储。缺失最左列 city 时，无法找到索引起始节点，优化器只能全表扫描。

---

2. 索引列参与运算

业务表：orders (id, user_id, amount, create_time)

索引：create_time

-- ❌ 错误示例
SELECT * FROM orders WHERE YEAR(create_time) = 2025;-- ✅ 正确示例
SELECT * FROM orders WHERE create_time BETWEEN '2025-01-01' AND '2025-12-31';

原因分析：

B+ 树存储的是原始时间戳，计算后的年份无法匹配原始索引。范围查询能直接利用索引区间扫描，性能高。

---

3. 隐式类型转换

业务表：product (id, price VARCHAR)

-- ❌ 错误示例
SELECT * FROM product WHERE price = 100;-- ✅ 正确示例
SELECT * FROM product WHERE price = '100';

原因分析：

类型不匹配触发隐式转换，相当于函数运算，索引失效。正确做法保证查询值与列类型一致。

---

4. OR 连接非索引列

业务表：orders (user_id, status)

索引：user_id

-- ❌ 错误示例
SELECT * FROM orders WHERE user_id = 10 OR status = 'PENDING';-- ✅ 正确示例
SELECT * FROM orders WHERE user_id = 10
UNION
SELECT * FROM orders WHERE status = 'PENDING';

原因分析：

OR 条件中包含非索引列时，优化器需扫描整个表验证条件，索引无法生效。拆分查询或增加联合索引可解决。

---

5. 范围查询阻断索引

业务表：user (city, age, username)

联合索引：(city, age, username)

-- ❌ 错误示例
SELECT * FROM user WHERE city = 'Beijing' AND age > 25 AND username = 'Tom';-- ✅ 正确示例
SELECT * FROM user WHERE city = 'Beijing' AND username = 'Tom' AND age > 25;

原因分析：

范围查询会阻断索引后续列扫描，索引只能扫描 city → username 部分，age > 25 无法直接索引。

---

6. 不等于查询

-- ❌ 错误示例
SELECT * FROM user WHERE status != 'ACTIVE';-- ✅ 正确示例
SELECT * FROM user WHERE status = 'INACTIVE';

原因分析：

不等于查询涉及大部分数据，优化器选择全表扫描，索引不再被使用。

---

7. LIKE 左模糊匹配

-- ❌ 错误示例
SELECT * FROM product WHERE name LIKE '%Phone';-- ✅ 正确示例
SELECT * FROM product WHERE name LIKE 'iPhone%';

原因分析：

B+ 树只能从字符串前缀开始匹配，左模糊破坏顺序，索引失效。

---

8. 索引选择性过低

-- ❌ 错误示例
SELECT * FROM user WHERE gender = 'M';-- ✅ 正确示例
SELECT * FROM user WHERE id = 1001;

原因分析：

性别列重复值多，选择性低，优化器估算全表扫描成本更低。

---

9. ORDER BY 排序方向混乱

-- ❌ 错误示例
SELECT * FROM user ORDER BY city ASC, age DESC;-- ✅ 正确示例
SELECT * FROM user ORDER BY city ASC, age ASC;

原因分析：

B+ 树索引顺序为 city ASC, age ASC，与查询排序方向不一致，索引无法直接排序。

---

10. 使用 NOT IN

-- ❌ 错误示例
SELECT * FROM orders WHERE id NOT IN (1,2,3);-- ✅ 正确示例
SELECT o.* FROM orders o
LEFT JOIN (SELECT 1 AS id UNION ALL SELECT 2 UNION ALL SELECT 3) t
ON o.id = t.id
WHERE t.id IS NULL;

原因分析：

NOT IN 等价于多个不等式，需要全表扫描。通过 LEFT JOIN + IS NULL 可利用索引。

---

11. 多表 JOIN 字符集不一致

-- ❌ 错误示例
SELECT u.id, o.id FROM user u JOIN orders o ON u.name = o.username;-- ✅ 正确示例
ALTER TABLE orders CONVERT TO CHARACTER SET utf8;

原因分析：

字符集不同触发转换，索引无法匹配，查询效率低。

---

12. 使用函数处理索引列

-- ❌ 错误示例
SELECT * FROM user WHERE LOWER(username) = 'alice';-- ✅ 正确示例
SELECT * FROM user WHERE username = 'Alice';

原因分析：

函数会破坏索引原始值匹配，导致全表扫描。

---

13. 使用变量表达式类型不一致

SET @uid := '1001';
-- ❌ 错误示例
SELECT * FROM orders WHERE user_id = @uid;-- ✅ 正确示例
SET @uid := 1001;
SELECT * FROM orders WHERE user_id = @uid;

原因分析：

变量类型与列类型不一致，触发隐式类型转换，索引失效。

---

14. 索引列存在 NULL

-- ❌ 错误示例
SELECT * FROM user WHERE city IS NULL;-- ✅ 正确示例
SELECT * FROM user WHERE city = 'Beijing';

原因分析：

NULL 值在索引中存储特殊，可能不走索引。

---

15. 分页深度过大

-- ❌ 错误示例
SELECT * FROM orders ORDER BY create_time LIMIT 100000, 10;-- ✅ 正确示例
SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 10;

原因分析：

深度分页 OFFSET 大时，优化器可能放弃索引，扫描大量无效行。

---

16. MATCH AGAINST 全文索引与普通索引混用

-- ❌ 错误示例
SELECT * FROM product WHERE MATCH(name) AGAINST('Phone') AND category='Electronics';-- ✅ 正确示例
SELECT * FROM product WHERE category='Electronics' AND id IN (SELECT id FROM product WHERE MATCH(name) AGAINST('Phone')
);

原因分析：

全文索引使用不同算法，与 B+ 树索引不兼容，需要分步查询。

---

17. 强制类型转换

-- ❌ 错误示例
SELECT * FROM orders WHERE CAST(id AS CHAR) = '1001';-- ✅ 正确示例
SELECT * FROM orders WHERE id = 1001;

原因分析：

显式转换破坏索引原始存储顺序，优化器无法利用索引。

---

18. 统计信息不准确

-- ❌ 错误示例
-- 数据量变化大，但未更新统计信息
SELECT * FROM orders WHERE user_id = 1001;-- ✅ 正确示例
ANALYZE TABLE orders;
SELECT * FROM orders WHERE user_id = 1001;

原因分析：

优化器基于统计信息判断成本，过时统计信息可能导致索引被放弃。

---

19. 使用派生表

-- ❌ 错误示例
SELECT * FROM (SELECT * FROM orders) t WHERE user_id = 1001;-- ✅ 正确示例
SELECT * FROM orders WHERE user_id = 1001;

原因分析：

派生表会生成临时表，索引下推失效。

---

20. 索引合并效率低下

-- ❌ 错误示例
SELECT * FROM orders WHERE user_id = 1001 AND status = 'PENDING';-- ✅ 正确示例
-- 建立联合索引 (user_id, status)
CREATE INDEX idx_user_status ON orders(user_id, status);
SELECT * FROM orders WHERE user_id = 1001 AND status = 'PENDING';

原因分析：

MySQL 对多个单列索引进行合并可能效率低于全表扫描，联合索引可提高效率。

---

三、索引优化黄金策略

索引优化不仅是避免失效，还要保证查询的可维护性和执行效率。提出 5C 原则，并加入 实际操作技巧，让优化更可执行。

1. Complete Coverage（完整覆盖）

目标：保证查询条件包含索引最左前缀。

说明：

• 联合索引 (a,b,c)，必须从 a 开始使用索引，否则 B+ 树无法快速定位起始节点。

• 对于业务查询 WHERE b=2 AND c=3，索引完全失效。

优化方法：

• 改写查询：WHERE a=1 AND b=2 AND c=3

• 对高频查询列设计最左前缀列

示例：

-- 联合索引 city, age, username
SELECT * FROM user WHERE city='Beijing' AND age=25;

---

2. Clean Calculation（避免计算）

目标：索引列不使用运算或函数。

说明：

• B+ 树存储的是原始值，YEAR(create_time) 或 amount+10 会破坏索引匹配。

优化方法：

• 使用范围查询替代函数

• 预计算字段或生成列（generated column）

示例：

-- 错误
SELECT * FROM orders WHERE YEAR(create_time)=2023;-- 正确
SELECT * FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';

---

3. Consistent Type（类型一致）

目标：保证查询值类型与列类型一致。

说明：

• 隐式类型转换会触发函数运算，导致索引失效。

• 常见场景：VARCHAR 字段用数字查询，或整数列用字符串查询。

优化方法：

• 查询值与列类型严格一致

• 对动态变量进行类型检查

示例：

-- 错误
SELECT * FROM product WHERE price=100; -- price VARCHAR-- 正确
SELECT * FROM product WHERE price='100';

---

4. Controlled Range（控制范围）

目标：范围查询放在联合索引最右侧。

说明：

• 范围查询如 >、<、BETWEEN 会阻断索引后续列扫描。

• 例如 (city, age, username) 索引，条件 city='Beijing' AND age>25 AND username='Tom'，age>25 阻断 username 索引。

优化方法：

• 将范围查询放在联合索引最右

• 对于复杂查询，可拆分查询或添加额外索引

示例：

SELECT * FROM user WHERE city='Beijing' AND username='Tom' AND age>25;

---

5. Cost Consideration（成本考量）

目标：在选择索引时考虑选择性和全表扫描成本。

说明：

• 低选择性索引可能导致优化器选择全表扫描。

• 判断标准：COUNT(DISTINCT col)/COUNT(*) < 0.2，慎用索引

1. 什么是低选择性列

• 选择性（Selectivity） = 不同值的数量 / 总行数
• 低选择性列：不同值少，比如性别字段 gender（只有 男/女 两种），启用状态字段 is_enabled（通常 0/1）
• 高选择性列：不同值多，比如身份证号、手机号、订单号

---

2. 为什么低选择性列建索引意义不大

• 假设表 user 有 1000 万条记录：

• gender 字段索引：

  • 男 = 500 万条，女 = 500 万条 * 查询 WHERE gender='男' 时，索引只帮助定位到 500
    万条记录 * 实际扫描行数几乎与全表扫描相同

• 优化器会判断：使用索引的成本 > 全表扫描成本

  • 结果是可能不会走索引 * 建索引浪费空间和维护成本（插入/更新时索引需要维护）

6. 扩展优化策略

1. 覆盖索引：查询字段全部包含在索引中，可避免访问表数据。

2. 分区索引：大表可以通过分区减少全表扫描范围。

3. 深度分页优化：使用 id > last_id 替代大 OFFSET。

4. 索引 NULL 处理：尽量避免索引列包含大量 NULL 值，或者为 NULL 建专门索引。

---

四、实战检测工具

1. EXPLAIN 分析

EXPLAIN SELECT * FROM orders WHERE user_id=1001;

• type 列：

  • ref/range：有效索引
  • ALL：全表扫描，索引失效

• key 列：显示使用的索引名称

• rows 列：扫描行数，可判断优化效果

示例：

id | select_type | table  | type | key       | rows
1  | SIMPLE      | orders | ref  | idx_user  | 10

说明索引 idx_user 有效，扫描 10 行。

---

2. 优化器追踪

SET optimizer_trace="enabled=on";
SELECT * FROM orders WHERE user_id=1001;
SELECT * FROM information_schema.optimizer_trace;

• 可查看优化器决策过程

• 追踪索引使用、JOIN 顺序、条件下推等细节

• 有助于排查索引失效根因

---

3. 索引使用分析

SHOW INDEX FROM orders;

• 查看表索引结构、列顺序、唯一性

• 确认是否存在联合索引和覆盖索引

示例：

字段	含义
Table	表名
Non_unique	是否唯一索引：0=唯一，1=非唯一
Key_name	索引名称
Seq_in_index	列在索引中的顺序（最左前缀）
Column_name	列名
Collation	索引列排序方式：A=升序
Cardinality	基数（估算唯一值数量）
Sub_part	前缀索引长度（NULL表示全列索引）
Packed	索引是否压缩
Null	列是否允许 NULL
Index_type	索引类型（BTREE, HASH 等）
Comment	注释
Index_comment	索引注释

---

4. 性能对比验证

• 建立测试表，执行错误和优化查询

• 使用 SELECT SQL_NO_CACHE ... 避免缓存影响

• 记录查询耗时、扫描行数

示例：

-- 错误查询
SELECT * FROM orders WHERE YEAR(create_time)=2025;  -- 扫描 100000 行，耗时 500ms-- 优化查询
SELECT * FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';  -- 扫描 500 行，耗时 2ms

---

5. 定期维护

1. ANALYZE TABLE：更新统计信息

2. OPTIMIZE TABLE：清理碎片，提高索引扫描效率

3. 监控慢查询日志：发现索引失效和全表扫描

---

五、总结

索引失效是数据库性能优化中的高频问题，核心在于理解 B+ 树结构和优化器决策逻辑。通过：

• 遵循 5C 原则

• 避免函数运算、隐式类型转换

• 控制范围查询顺序

• 分析优化器决策

• 使用覆盖索引和分区索引

可以显著提高查询效率，降低全表扫描风险。