371 lines
14 KiB
Markdown
371 lines
14 KiB
Markdown
---
|
||
tags: [MySQL, 索引, EXPLAIN, 查询优化, B+Tree]
|
||
create time: 2026-05-21 13:08
|
||
---
|
||
|
||
# 索引失效情况
|
||
|
||
## 概述
|
||
|
||
明明建了索引，EXPLAIN 却显示 `type: ALL`——这种"索引建了等于没建"的情况在线上非常常见。本文系统梳理导致索引失效（或退化）的所有典型场景，并结合 B+ Tree 的底层原理给出每条规则的解释，帮你从"背规则"升级到"理解为什么"。
|
||
|
||
## 正文
|
||
|
||
### 速查总览
|
||
|
||
> [!tip] 先看全景图再逐条深入
|
||
> 下图把常见的索引失效场景按"谁导致的"做了分类，后文逐一展开。
|
||
|
||
```mermaid
|
||
mindmap
|
||
root(("索引失效"))
|
||
("SQL 写法问题")
|
||
("隐式类型转换")
|
||
("对索引列使用函数")
|
||
("索引列参与运算")
|
||
("LIKE 左模糊")
|
||
("违反最左前缀")
|
||
("范围查询截断后续列")
|
||
("SELECT * 阻止覆盖索引")
|
||
("OR 条件不当")
|
||
("NOT IN / NOT EXISTS")
|
||
("!= / <> / NOT LIKE")
|
||
("数据与优化器")
|
||
("优化器选择全表扫描")
|
||
("隐式字符集转换")
|
||
("IS NULL / IS NOT NULL")
|
||
```
|
||
|
||
---
|
||
|
||
### 1. 隐式类型转换
|
||
|
||
**现象**：`varchar` 列上建了索引，但用数值条件查询时索引失效。
|
||
|
||
```sql
|
||
-- 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 左模糊 / 两侧模糊
|
||
|
||
```sql
|
||
SELECT * FROM products WHERE name LIKE '%手机'; -- ❌ 全表扫描
|
||
SELECT * FROM products WHERE name LIKE '手机%'; -- ✅ 走索引
|
||
SELECT * FROM products WHERE name LIKE '%手机%'; -- ❌ 全表扫描
|
||
```
|
||
|
||
**原理**：B+ Tree 按前缀有序排列。`'手机%'` 可以通过前缀定位到范围起点，而 `'%手机'` 左侧是未知的，无法利用有序性，只能全量遍历。
|
||
|
||
> [!tip] 模糊搜索的替代方案
|
||
> 如果业务确实需要前后模糊匹配，可以考虑：
|
||
> - **覆盖索引**：索引包含所有查询字段，避免回表开销（虽然仍是全扫索引，但比扫聚簇索引快得多）
|
||
> - **全文索引**（`FULLTEXT`）或外部搜索引擎（Elasticsearch）
|
||
|
||
---
|
||
|
||
### 3. 对索引列使用函数
|
||
|
||
```sql
|
||
-- ❌ 索引失效：对 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. 索引列参与运算
|
||
|
||
```sql
|
||
-- ❌ 对索引列做了运算
|
||
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%'`），**该列之后的索引列将无法继续用于索引定位**。
|
||
|
||
```sql
|
||
-- 联合索引 (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 * 导致无法走覆盖索引
|
||
|
||
```sql
|
||
-- 假设有联合索引 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 条件不当（一侧无索引）
|
||
|
||
```sql
|
||
-- ❌ 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 / != / <>
|
||
|
||
```sql
|
||
-- 以下写法可能导致索引失效（取决于数据分布和优化器判断）
|
||
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
|
||
|
||
```sql
|
||
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 查找更快 |
|
||
| 统计信息过期 | 优化器误判行数，做出错误决策 |
|
||
|
||
```sql
|
||
-- 用 FORCE INDEX 强制走索引（仅用于验证，不建议生产使用）
|
||
SELECT * FROM orders FORCE INDEX(idx_create_time)
|
||
WHERE create_time > '2026-01-01';
|
||
```
|
||
|
||
> [!note] 保持统计信息准确
|
||
> `ANALYZE TABLE table_name` 可以刷新表的统计信息，帮助优化器做出更准确的判断。
|
||
|
||
---
|
||
|
||
### 12. 隐式字符集 / 排序规则转换
|
||
|
||
当 `JOIN` 两张表的关联字段字符集不一致时，MySQL 会对其中一列做隐式转换，导致该列的索引失效。
|
||
|
||
```sql
|
||
-- 表 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()` 到低优先级字符集侧。
|
||
|
||
---
|
||
|
||
### 排查速查清单
|
||
|
||
当怀疑索引失效时，按以下流程排查：
|
||
|
||
```mermaid
|
||
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**
|
||
|
||
```sql
|
||
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` 上有索引也会失效。更关键的是，这个条件让优化器评估后觉得"算了，全扫吧"。
|
||
|
||
**第三步：改写并验证**
|
||
|
||
```sql
|
||
-- 去掉函数，改写为范围
|
||
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`，可以建覆盖索引：
|
||
|
||
```sql
|
||
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；函数和类型，是最常见的坑。**
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/MySQL/03-索引与查询优化/14-联合索引与最左前缀]]
|
||
- [[hhs/MySQL/03-索引与查询优化/15-EXPLAIN 完全指南]]
|
||
- [[hhs/MySQL/03-索引与查询优化/17-查询改写技巧]]
|
||
- [[hhs/MySQL/03-索引与查询优化/12-B+Tree 索引原理]]
|