198 lines
7.5 KiB
Markdown
198 lines
7.5 KiB
Markdown
---
|
||
tags: [MySQL, 联合索引, 最左前缀, 索引失效]
|
||
create time: 2026-05-16 00:00
|
||
---
|
||
|
||
# 联合索引与最左前缀
|
||
|
||
## 概述
|
||
|
||
联合索引（Composite Index）是将多个列放在同一个 B+ Tree 中组织的索引。它的核心法则是**最左前缀匹配原则**——理解这一点就能避开 80% 的索引设计失误。
|
||
|
||
## 联合索引的结构
|
||
|
||
```
|
||
联合索引 idx(a, b, c) 的 B+ Tree 结构：
|
||
|
||
叶子节点按 a 排序，a 相同时按 b 排序，a 和 b 都相同时按 c 排序：
|
||
|
||
[a=1, b=10, c=3] → data
|
||
[a=1, b=10, c=7] → data
|
||
[a=1, b=20, c=1] → data
|
||
[a=1, b=20, c=9] → data
|
||
[a=2, b=5, c=2] → data
|
||
[a=2, b=15, c=4] → data
|
||
[a=3, b=10, c=1] → data
|
||
[a=3, b=10, c=8] → data
|
||
[a=3, b=30, c=5] → data
|
||
```
|
||
|
||
> [!QUESTION] 这意味着什么？
|
||
> 联合索引的本质是**多级排序**。你可以把它想象成 SQL 的 `ORDER BY a, b, c`。索引中的数据已经按照这个顺序排好了。
|
||
|
||
## 最左前缀法则详解
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
IDX["联合索引 idx(a, b, c)"]
|
||
|
||
IDX --> U1["✅ WHERE a=1"]
|
||
IDX --> U2["✅ WHERE a=1 AND b=2"]
|
||
IDX --> U3["✅ WHERE a=1 AND b=2 AND c=3"]
|
||
IDX --> X1["❌ WHERE b=2"]
|
||
IDX --> X2["❌ WHERE c=3"]
|
||
IDX --> X3["❌ WHERE b=2 AND c=3"]
|
||
IDX --> U4["⚠️ WHERE a=1 AND c=3"]
|
||
|
||
U1 -. "用 1 列" .-> _u1
|
||
U2 -. "用 2 列" .-> _u2
|
||
U3 -. "用全部" .-> _u3
|
||
X1 -. "无效" .-> _x1
|
||
X2 -. "无效" .-> _x2
|
||
X3 -. "无效" .-> _x3
|
||
U4 -. "仅用 a" .-> _u4
|
||
|
||
style U1 fill:#00D866,color:#fff
|
||
style U2 fill:#00D866,color:#fff
|
||
style U3 fill:#00D866,color:#fff
|
||
style X1 fill:#EE5A24,color:#fff
|
||
style X2 fill:#EE5A24,color:#fff
|
||
style X3 fill:#EE5A24,color:#fff
|
||
style U4 fill:#FF9F43,color:#000
|
||
```
|
||
|
||
### 为什么 b=2 单独查不了？
|
||
|
||
```
|
||
查询 WHERE b=2 时，B+ Tree 的搜索路径是什么样的？
|
||
|
||
[b=20, c=1] 的位置在 [b=10, c=7] 之后，但它们之间穿插着 [b=5, c=2]...
|
||
数据在整个树中分散存放，没有连续的 b=2 区域 → 需要全树扫描
|
||
|
||
而 WHERE a=1 则不同：
|
||
[a=1, ...] 的所有记录都在树的左侧一段连续区域内 → 二分查找即可定位
|
||
```
|
||
|
||
## 范围查询后的断裂
|
||
|
||
联合索引遇到范围查询（`>`, `<`, `BETWEEN`, `LIKE 'prefix%'`）后，右侧列的索引失效。
|
||
|
||
```sql
|
||
-- 假设已有联合索引 idx(status, created_at, type)
|
||
|
||
-- ⚠️ 看起来像用上了 3 个列，实际上 type 不会走索引！
|
||
SELECT * FROM orders WHERE status = 'paid'
|
||
AND created_at > '2026-01-01' AND type = 'online';
|
||
|
||
-- 逐列分析：
|
||
-- status = 'paid' → ✅ 等值匹配，精确定位起始行
|
||
-- created_at > ... → ✅ 范围扫描，划定区间终点
|
||
-- type = 'online' → ❌ 区间内数据未按 type 排序 → 退化为内存过滤
|
||
```
|
||
|
||
> [!QUESTION] 为什么范围查询会打断后续列？
|
||
> 想象一下，当 `status='paid'` 锁定一个子树后，该子树内部按 `created_at` 升序排列。一旦用 `>` 做了范围扫描，得到的是一个 `created_at` 连续递增的数据段——这个段内的 `type` 值是乱序穿插的，无法再用二分查找定位 `type='online'`。
|
||
|
||
```mermaid
|
||
graph LR
|
||
A["等值列 = 定位起点"] -->|"精确找到起始位置"| B
|
||
B["范围列 = 确定终点"] -->|"划定扫描区间"| C
|
||
C["右侧列 = 失效"] -->|"区间内无序"| D["退化为 WHERE 过滤"]
|
||
|
||
style A fill:#00D866,color:#fff
|
||
style B fill:#00B6BC,color:#fff
|
||
style D fill:#EE5A24,color:#fff
|
||
```
|
||
|
||
### 实战：调整联合索引的顺序
|
||
|
||
```sql
|
||
-- 场景：订单表常用查询——按状态筛选 + 按时间范围 + 按类型过滤
|
||
|
||
-- ❌ 原始索引：范围列在中间，后续等值列无法使用
|
||
CREATE INDEX idx_sct ON orders (status, created_at, type);
|
||
-- 查询 A: WHERE status=? AND created_at>? AND type=?
|
||
-- → type 无法用索引（created_at 的范围扫描打断了后续列）
|
||
|
||
-- ✅ 优化方案 1：将等值列提前
|
||
CREATE INDEX idx_stc ON orders (status, type, created_at);
|
||
-- 查询 B: WHERE status=? AND type=? AND created_at>?
|
||
-- → 三个列全部用上！status 定位起点，type 进一步缩小，created_at 做范围
|
||
-- 💡 注意：即使 SQL 写的是 created_at 在前，优化器也会自动调整顺序匹配索引
|
||
|
||
-- ✅ 优化方案 2：如果两个查询频率差不多，拆成两个索引
|
||
CREATE INDEX idx_status ON orders (status);
|
||
CREATE INDEX idx_status_time ON orders (status, created_at);
|
||
-- 让每个索引专注于它的典型查询模式
|
||
```
|
||
|
||
> [!TIP] 联合索引列序黄金法则
|
||
> 1. **等值优先于范围**：等值列放在前面
|
||
> 2. **选择性高的列靠前**：区分度大的列（如 user_id）比区分度小的（如 gender）靠前
|
||
> 3. **前缀长度要短**：如果需要 LIKE，尽量用较短的前缀
|
||
|
||
## 索引失效的典型场景
|
||
|
||
```sql
|
||
-- ❌ 场景 1：隐式类型转换
|
||
ALTER TABLE users ADD INDEX idx_phone (phone);
|
||
-- phone 是 VARCHAR 类型
|
||
SELECT * FROM users WHERE phone = 13800138000; -- 传入 INT！
|
||
-- MySQL 会把 varchar 转成 int 再比较 → 函数作用于列 → 索引失效
|
||
|
||
-- ❌ 场景 2：函数/表达式包裹索引列
|
||
SELECT * FROM users WHERE YEAR(created_at) = 2026;
|
||
-- 应对：改为范围查询 WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01'
|
||
|
||
-- ❌ 场景 3：LIKE 以通配符开头
|
||
SELECT * FROM users WHERE name LIKE '%abc%';
|
||
-- 应对：考虑全文索引 FT
|
||
|
||
-- ❌ 场景 4：OR 条件中有列没有索引
|
||
SELECT * FROM users WHERE email = 'a@x.com' OR phone = '138...';
|
||
-- 如果 email 有索引但 phone 没有，整个查询不走索引
|
||
-- 应对：给 phone 加索引，或用 UNION ALL 拆分
|
||
|
||
-- ❌ 场景 5：字符集不一致导致隐式转换
|
||
-- 表 charset=utf8mb4，客户端 charset=gbk → 自动转换
|
||
-- 应对：确保连接字符集一致 SET NAMES utf8mb4
|
||
```
|
||
|
||
## 最左前缀的灵活应用
|
||
|
||
一个设计良好的联合索引可以**同时服务 WHERE、ORDER BY、GROUP BY 三种需求**。
|
||
|
||
```sql
|
||
-- 建索引：idx(status, type, created_at)
|
||
CREATE INDEX idx_status_type_time ON orders (status, type, created_at);
|
||
|
||
-- ── 查询 1：等值 + 范围 ──
|
||
SELECT * FROM orders WHERE status = 'pending'
|
||
AND created_at > '2026-01-01';
|
||
-- → status 等值定位起点，created_at 范围扫描。type 虽在中间但没用到，不影响前两列生效
|
||
|
||
-- ── 查询 2：利用 ORDER BY ──
|
||
SELECT * FROM orders WHERE status = 'pending'
|
||
ORDER BY type ASC;
|
||
-- → WHERE 条件锁定了 status='pending' 的子区间，该区间内数据天然按 type 排序
|
||
-- → 无需额外 filesort！
|
||
|
||
-- ── 查询 3：利用 GROUP BY ──
|
||
SELECT type, COUNT(*) FROM orders WHERE status = 'pending'
|
||
GROUP BY type;
|
||
-- → 同上，子区间内 type 已有序，分组可以直接跳过
|
||
```
|
||
|
||
> [!NOTE] 关键理解
|
||
> ORDER BY / GROUP BY 能复用联合索引，靠的不是"巧合"，而是 B+ Tree **叶子节点本身有序**这一物理特性。只要 WHERE 过滤条件匹配了联合索引的左侧列，剩余列就是有序的——优化器只是利用了已有的顺序，并没有多做一次排序。
|
||
|
||
> [!TIP] 一索引多用
|
||
> 一个好的联合索引可以同时服务 WHERE、ORDER BY、GROUP BY 三种需求。在设计索引时要考虑查询的整体模式，而不是单一查询。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/MySQL/17-聚簇索引与二级索引]] — 聚簇索引本身就是特殊的联合索引 (PK)
|
||
- [[hhs/MySQL/19-EXPLAIN 完全指南]] — 用 EXPLAIN 验证联合索引是否按预期生效
|
||
- [[hhs/MySQL/20-慢查询日志分析]] — 如何从 slow log 中识别索引未命中
|
||
- [[hhs/MySQL/21-查询改写技巧]] — 将失效的查询改写为可利用索引的形式
|