14 KiB
tags, create time
| tags | create time | |||||
|---|---|---|---|---|---|---|
|
2026-05-21 13:08 |
索引失效情况
概述
明明建了索引，EXPLAIN 却显示 type: ALL——这种"索引建了等于没建"的情况在线上非常常见。本文系统梳理导致索引失效（或退化）的所有典型场景，并结合 B+ Tree 的底层原理给出每条规则的解释，帮你从"背规则"升级到"理解为什么"。
正文
速查总览
[!tip] 先看全景图再逐条深入 下图把常见的索引失效场景按"谁导致的"做了分类，后文逐一展开。
mindmap
root(("索引失效"))
("SQL 写法问题")
("隐式类型转换")
("对索引列使用函数")
("索引列参与运算")
("LIKE 左模糊")
("违反最左前缀")
("范围查询截断后续列")
("SELECT * 阻止覆盖索引")
("OR 条件不当")
("NOT IN / NOT EXISTS")
("!= / <> / NOT LIKE")
("数据与优化器")
("优化器选择全表扫描")
("隐式字符集转换")
("IS NULL / IS NOT NULL")
1. 隐式类型转换
现象：varchar 列上建了索引，但用数值条件查询时索引失效。
-- phone 是 varchar 类型
SELECT * FROM users WHERE phone = 13800138000; -- ❌ 索引失效
SELECT * FROM users WHERE phone = '13800138000'; -- ✅ 走索引
原理：MySQL 的类型转换规则是将字符串转为数字——相当于对索引列执行了 CAST(phone AS DECIMAL)。对索引列施加函数，B+ Tree 无法直接定位，只能逐行扫描。
[!question] 反过来呢？数值列用字符串查会失效吗？ 不会。
WHERE id = '123'（id 是int）等价于WHERE id = 123，因为'123'被转为数字后直接用于比较，不涉及对索引列的函数调用。
2. LIKE 左模糊 / 两侧模糊
SELECT * FROM products WHERE name LIKE '%手机'; -- ❌ 全表扫描
SELECT * FROM products WHERE name LIKE '手机%'; -- ✅ 走索引
SELECT * FROM products WHERE name LIKE '%手机%'; -- ❌ 全表扫描
原理：B+ Tree 按前缀有序排列。'手机%' 可以通过前缀定位到范围起点，而 '%手机' 左侧是未知的，无法利用有序性，只能全量遍历。
[!tip] 模糊搜索的替代方案 如果业务确实需要前后模糊匹配，可以考虑：
- 覆盖索引：索引包含所有查询字段，避免回表开销（虽然仍是全扫索引，但比扫聚簇索引快得多）
- 全文索引（
FULLTEXT）或外部搜索引擎（Elasticsearch）
3. 对索引列使用函数
-- ❌ 索引失效：对 create_time 调用了 YEAR() 函数
SELECT * FROM orders WHERE YEAR(create_time) = 2026;
-- ✅ 改写为范围查询，可以走索引
SELECT * FROM orders WHERE create_time >= '2026-01-01'
AND create_time < '2027-01-01';
原理：函数包裹索引列后，MySQL 拿到的不再是原始列值，而是函数的返回值。B+ Tree 上存的是原始值，无法对函数结果做二分查找。
常见的"隐形函数"还有：
| 写法 | 等价函数调用 |
|---|---|
WHERE DATE(col) = '2026-05-21' |
DATE(col) |
WHERE col + 1 = 10 |
加法运算（见下节） |
WHERE CONCAT(col, 'x') = 'abx' |
CONCAT(col, 'x') |
[!question] MySQL 8.0 的索引下推（ICP）能救吗？ 不能。ICP（Index Condition Pushdown）优化的是回表前的过滤，前提仍是索引被命中。如果函数导致索引根本没用上，ICP 无从谈起。
4. 索引列参与运算
-- ❌ 对索引列做了运算
SELECT * FROM accounts WHERE balance - 100 > 0;
-- ✅ 把运算移到右边（常量侧）
SELECT * FROM accounts WHERE balance > 100;
原理：与函数同理——balance - 100 对每一行的 balance 做运算后才能比较，B+ Tree 上存的是 balance 原始值，无法直接定位。
准则：索引列保持"干净"，运算和函数尽量放到等号右侧。
5. 违反联合索引的最左前缀原则
假设联合索引为 (a, b, c)：
| WHERE 条件 | 能否走索引 | 走到哪一列 |
|---|---|---|
a = 1 |
✅ | a |
a = 1 AND b = 2 |
✅ | a, b |
a = 1 AND b = 2 AND c = 3 |
✅ | a, b, c |
b = 2 |
❌ | — |
b = 2 AND c = 3 |
❌ | — |
a = 1 AND c = 3 |
⚠️ 部分 | a（c 无法跳过 b 使用） |
原理：联合索引在 B+ Tree 中按 a → b → c 的顺序排序。没有 a 就无法确定在树中的起始位置，就像查字典时不知道首字母一样。
[!tip] MySQL 8.0+ 的索引跳跃扫描（Index Skip Scan） 当联合索引首列基数（cardinality）很低时（例如
gender只有 M/F），优化器可能拆分成两次索引查询，绕过最左前缀限制。但这只是优化器的"兜底"策略，不应依赖。
6. 范围查询截断联合索引的后续列
联合索引 (a, b, c) 中，一旦某列使用了范围查询（>、<、BETWEEN、LIKE 'x%'），该列之后的索引列将无法继续用于索引定位。
-- 联合索引 (a, b, c)
WHERE a = 1 AND b > 10 AND c = 20;
-- a: ✅ 等值定位
-- b: ✅ 范围扫描（在 a=1 的范围内做 b > 10）
-- c: ❌ 无法走索引（b 是范围，c 被"截断"）
原理：B+ Tree 先按 a 排序，a 相同时按 b 排序，b 相同时按 c 排序。当 b > 10 时，b 的值不再固定，那么同一个 b 值下可能对应不同的 c，c 在树中不再有序，无法二分查找。
[!question] 那
BETWEEN和LIKE 'x%'也会截断吗？ 是的。BETWEEN 1 AND 100本质也是范围，LIKE '张%'同理——它们都让该列的值不再唯一确定，后续列的有序性被破坏。
[!tip] 实战优化思路 在设计联合索引时，等值查询的列放在前面，范围查询的列放在后面。例如，如果查询经常是
WHERE status = 'active' AND create_time > '2026-01-01'，索引应设计为(status, create_time)而非(create_time, status)。
7. SELECT * 导致无法走覆盖索引
-- 假设有联合索引 idx_name_age (name, age)
-- ✅ 覆盖索引：查询字段全在索引中，无需回表
SELECT name, age FROM users WHERE name = '张三';
-- ❌ SELECT * 强制回表：即使 WHERE 走了索引，仍需回表取其他列
SELECT * FROM users WHERE name = '张三';
原理：覆盖索引（Covering Index）是指查询所需的所有字段都包含在索引中，MySQL 可以直接从索引返回结果，省去"回表"（回到聚簇索引取完整行）的开销。SELECT * 取所有列，索引中不可能全部包含，因此必定回表。
[!question] 回表代价有多大？ 每次回表都是一次随机 I/O。如果查询匹配 10 万行，就要做 10 万次随机读。这就是为什么
SELECT *+ 大量行 = 慢查询的经典组合。通过
EXPLAIN查看Extra列：出现Using index表示走覆盖索引，出现Using index condition表示走了索引但仍需回表。
[!tip] 最佳实践
- 生产代码中禁止
SELECT *，只查需要的列- 为高频查询设计"覆盖索引"——把
SELECT中的字段也加入联合索引尾部- 注意：索引列过多会增大写入代价，需权衡
8. OR 条件不当（一侧无索引）
-- ❌ name 有索引，age 没索引 → 整体退化为全表扫描
SELECT * FROM users WHERE name = '张三' OR age = 25;
-- ✅ 用 UNION ALL 拆开，各自走各自的索引
SELECT * FROM users WHERE name = '张三'
UNION ALL
SELECT * FROM users WHERE age = 25 AND name != '张三';
原理：OR 要求两边条件取并集。如果其中一个条件无索引，MySQL 只能对全表扫描来保证结果完整。
[!note] 如果 OR 两边的列都有索引呢？ MySQL 会分别用两个索引扫描，再合并结果（
index_merge优化），通常是能走索引的。
9. NOT IN / NOT EXISTS / != / <>
-- 以下写法可能导致索引失效（取决于数据分布和优化器判断）
SELECT * FROM orders WHERE status != 'completed';
SELECT * FROM users WHERE id NOT IN (1, 2, 3);
SELECT * FROM users WHERE name NOT LIKE '张%';
原理：不等于 / 不在集合中 / 不匹配，本质上是排除操作——需要扫描大量行来确认"不等于"，优化器通常评估后认为全表扫描更快。
[!question] 那 NOT EXISTS 一定比 NOT IN 慢吗？ 恰恰相反。
NOT EXISTS使用关联子查询，往往能在子查询表上走索引；而NOT IN需要将子查询结果物化后逐一比对，当结果集大时更慢。但在"索引是否失效"这个维度，两者的行为取决于执行计划，不能一概而论。
10. IS NULL / IS NOT NULL
SELECT * FROM users WHERE email IS NULL;
SELECT * FROM users WHERE email IS NOT NULL;
- MySQL 5.6：
IS NULL可以走索引，IS NOT NULL通常不能。 - MySQL 8.0+：两者都可以走索引，优化器会根据数据分布自行判断——如果大部分行都是
NULL，IS NOT NULL反而更高效地走索引。
[!tip] 设计层面的建议 在设计表时，如果某列经常需要查询"非空"的记录，可以考虑将默认值设为一个特殊标记（如空字符串或
0），避免频繁IS NULL / IS NOT NULL判断。
11. 优化器主动放弃索引
即使索引"理论上"可用，优化器也可能主动选择全表扫描。
核心判断逻辑：优化器基于成本估算做决策——当回表代价高于直接全扫时，索引就会被放弃。
常见场景：
| 场景 | 原因 |
|---|---|
| 查询返回表中超过 20%~30% 的行 | 回表次数太多，不如顺序扫描 |
| 表数据量很小（几百行以内） | 顺序扫描比 B+ Tree 查找更快 |
| 统计信息过期 | 优化器误判行数，做出错误决策 |
-- 用 FORCE INDEX 强制走索引（仅用于验证，不建议生产使用）
SELECT * FROM orders FORCE INDEX(idx_create_time)
WHERE create_time > '2026-01-01';
[!note] 保持统计信息准确
ANALYZE TABLE table_name可以刷新表的统计信息，帮助优化器做出更准确的判断。
12. 隐式字符集 / 排序规则转换
当 JOIN 两张表的关联字段字符集不一致时，MySQL 会对其中一列做隐式转换，导致该列的索引失效。
-- 表 A: name VARCHAR(50) CHARSET utf8mb4 COLLATE utf8mb4_general_ci
-- 表 B: name VARCHAR(50) CHARSET utf8 COLLATE utf8_general_ci
SELECT * FROM A JOIN B ON A.name = B.name;
-- B.name 会被隐式转换为 utf8mb4，B 表侧索引可能失效
解决：统一字符集和排序规则，或显式 CONVERT() 到低优先级字符集侧。
排查速查清单
当怀疑索引失效时，按以下流程排查：
flowchart TD
A["怀疑索引失效"] --> B["EXPLAIN 查看执行计划"]
B --> C{"type = ALL?"}
C -->|"是"| D["检查 WHERE 条件"]
C -->|"否"| E["索引已命中, 检查其他慢点"]
D --> F{"索引列被函数/运算包裹?"}
F -->|"是"| G["改写: 函数/运算移到常量侧"]
F -->|"否"| H{"存在隐式类型转换?"}
H -->|"是"| I["统一参数类型与列类型"]
H -->|"否"| J{"联合索引是否满足最左前缀?"}
J -->|"否"| K["调整索引或查询条件顺序"]
J -->|"是"| L{"范围查询是否截断后续列?"}
L -->|"是"| M["调整索引列顺序: 等值在前, 范围在后"]
L -->|"否"| N{"OR 条件中有无索引列?"}
N -->|"是"| O["UNION ALL 拆分或补充索引"]
N -->|"否"| P["考虑数据分布, ANALYZE TABLE"]
实战：从一个慢查询到修复的全过程
[!example] 真实场景还原 线上告警：某订单查询接口 P99 耗时 3 秒。表
orders约 500 万行，已有联合索引idx_status_time(status, create_time)。
第一步：拿到 SQL，跑 EXPLAIN
EXPLAIN SELECT * FROM orders
WHERE status = 'pending'
AND create_time > '2026-05-01'
AND YEAR(update_time) = 2026;
+----+------+------+----------+----------+
| id | type | key | key_len | Extra |
+----+------+------+----------+----------+
| 1 | ALL | NULL | NULL | Using where |
+----+------+------+----------+----------+
type = ALL，key = NULL——索引完全没用上。
第二步：逐条排查
status = 'pending'：等值查询，无问题。create_time > '2026-05-01'：范围查询，索引(status, create_time)可以覆盖前两列。YEAR(update_time) = 2026：函数包裹了索引列——如果update_time上有索引也会失效。更关键的是，这个条件让优化器评估后觉得"算了，全扫吧"。
第三步：改写并验证
-- 去掉函数，改写为范围
EXPLAIN SELECT * FROM orders
WHERE status = 'pending'
AND create_time > '2026-05-01'
AND update_time >= '2026-01-01'
AND update_time < '2027-01-01';
+----+-------+----------------+---------+-----------------------------+
| id | type | key | key_len | Extra |
+----+-------+----------------+---------+-----------------------------+
| 1 | range | idx_status_time| 68 | Using index condition |
+----+-------+----------------+---------+-----------------------------+
type = range，索引命中！但 Extra 显示 Using index condition（ICP），说明仍需回表。
第四步：进一步优化——覆盖索引
如果这个接口只需要 order_id, status, amount，可以建覆盖索引：
ALTER TABLE orders ADD INDEX idx_cover(status, create_time, order_id, amount);
改写查询为 SELECT order_id, status, amount FROM orders WHERE ...，Extra 将变为 Using index，彻底消除回表。
[!tip] 排查口诀 先 EXPLAIN，看 type 和 key；再看 Extra，找 Using index；函数和类型，是最常见的坑。