18 KiB
18 KiB
tags, create time
| tags | create time | ||||
|---|---|---|---|---|---|
|
2026-05-16 00:00 |
B+ Tree 索引原理
概述
MySQL InnoDB 的索引默认使用 B+ Tree（Balance Plus Tree）。理解它的工作方式是掌握所有索引优化技巧的前提。
为什么用 B+ Tree？
flowchart LR
BT["B+ Tree<br/>多路平衡树"] --> W1["胜出的原因"]
BT2["B Tree<br/>传统平衡树"] --> W2["缺点"]
HT["Hash<br/>哈希表"] --> W3["缺陷"]
BST["RBTree<br/>二叉平衡树"] --> W4["不适合磁盘"]
W1 -.->|"范围扫描 + 磁盘友好 + 叶子链表串联"| WINNER["✅ B+ Tree 胜出"]
W2 -.->|"非叶子也存数据 → IO 更多"| REASON
W3 -.->|"无范围查询能力"| REASON
W4 -.->|"树太高 IO 频繁"| REASON
style WINNER fill:#00D866,color:#fff
style BT fill:#00D866,color:#fff
关键差异点
| 特性 | B+ Tree | B Tree | Hash | 红黑树 |
|---|---|---|---|---|
| 范围查询 | ✅ 叶子节点链表遍历 | ❌ 需回溯祖先 | ❌ | ❌ |
| 全表扫描 | ✅ 顺序扫描叶子 | ❌ 需要层序遍历 | — | ❌ |
| 磁盘 IO 次数 | 低（阶数高，树矮） | 高 | O(1) 但仅等值 | 极高 |
| 插入删除稳定性 | ✅ 分裂/合并均衡 | ✅ | ❌ 缩容重哈希 | ✅ |
| 查询性能可预测 | ✅ 始终 O(logₘn) | ✅ | ⚠️ 冲突时退化 | ✅ |
B+ Tree 结构
flowchart TD
ROOT["根节点<br/>键: 15, 30, 45"] --> N1["内部节点<br/>键: 5, 10"]
ROOT --> N2["内部节点<br/>键: 20, 25"]
ROOT --> N3["内部节点<br/>键: 35, 40"]
ROOT --> N4["内部节点<br/>键: 50, 55"]
N1 --> LEAF1["[1][3][5][8][10]<br/>叶子 · 存数据 + 双向链表"]
N2 --> LEAF2["[12][15][20][22][25]"]
N3 --> LEAF3["[28][32][35][40][45]"]
N4 --> LEAF4["[48][50][52][55][60]"]
LEAF1 -.-> LEAF2 -.-> LEAF3 -.-> LEAF4
style ROOT fill:#4FC08D,color:#fff
style N1 fill:#A0AEC0,color:#fff
style N2 fill:#A0AEC0,color:#fff
style N3 fill:#A0AEC0,color:#fff
style N4 fill:#A0AEC0,color:#fff
style LEAF1 fill:#00B6BC,color:#fff
style LEAF2 fill:#00B6BC,color:#fff
style LEAF3 fill:#00B6BC,color:#fff
style LEAF4 fill:#00B6BC,color:#fff
核心特征
- 非叶子节点只存储键（Key）和指针，不存储完整数据行 —— 一个页可以放更多键，树更矮
- 所有数据存储在叶子节点，形成有序链表 —— 支持范围扫描
- 叶子节点之间通过双向链表连接 —— 相邻页面不用回溯父节点
- 所有叶子节点在同一深度 —— 查询性能稳定
为什么树这么矮？
InnoDB 一页 16KB（可配置），扣除页头 / 页尾等元数据开销后，实际可用空间约 14~15 KB。假设：
- 主键 BIGINT = 8 bytes
- 指针（Page Pointer）= 6 bytes
- 每个内部节点 Entry（Key + Pointer + 冗余信息）≈ 16 bytes
- 一页可存 ≈ 14.5 KB / 16 bytes ≈ 900 ~ 1170 个子节点（取保守值 1170）
flowchart LR
D1["1层<br/>1,170 行"] --> D2["2层<br/>约 137 万行"]
D2 --> D3["3层<br/>约 16 亿行"]
D3 --> D4["4层<br/>约 1900 亿行"]
style D1 fill:#A0AEC0,color:#fff
style D2 fill:#FF9F43,color:#000
style D3 fill:#00D866,color:#fff
style D4 fill:#EE5A24,color:#fff
[!TIP] 这意味着什么？ 即使是一张有 1 亿行的表，查找任意一条记录也只需要 3~4 次磁盘 IO（每次读取一个页）。这就是 B+ Tree 在磁盘介质上无可替代的原因。
[!QUESTION] 思考一下 如果每个内部节点只存一个键，那这棵树会变成什么样子？ ——退化成一棵二叉树（红黑树的高度）。所以 B+ Tree 的阶数越高，树越矮，IO 越少。
[!TIP] 直观感受 通过
information_schema.statistics查看索引基数，关注 CARDINALITY（基数）—— 基数接近总行数说明区分度高，索引效果好：-- 查看表的索引基数统计 SELECT INDEX_NAME, NON_UNIQUE, CARDINALITY FROM information_schema.statistics WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'users';
索引查找过程
sequenceDiagram
participant Q as "查询"
participant R as "根节点"
participant I as "内部节点"
participant L as "叶子节点"
participant D as "数据行"
Q->>R: "id > 30 → 右分支"
R->>I: "定位到第二层右子节点"
I->>L: "命中对应叶子节点"
L->>D: "读取完整行数据"
Note over Q,D:"总共 3 次随机 IO"
[!QUESTION] 思考一下 如果二级索引也存整行数据，还需要回表吗？ ——不需要了。这就是**覆盖索引（Covering Index）**的核心思想。
覆盖索引（Covering Index）
什么是回表？二级索引的叶子节点只存了索引列 + 主键，不存完整行数据。当查询需要的列不在索引中时，MySQL 必须拿着主键再去聚簇索引里找完整行——这个"再跳一次"的过程就叫回表（详见下方 #聚簇索引 vs 二级索引）。每回表一次就是一次随机 IO，匹配 1000 行就是 1000 次随机跳转，代价非常高。
覆盖索引的核心思想：如果查询所需的所有列都存在于某个索引的叶子节点中，就省掉回表这一步——直接从二级索引中把数据读完。这在 EXPLAIN 中显示为 Using index，也叫 Index Only Scan。
flowchart LR
subgraph "回表路径（普通查询）"
A1["二级索引<br/>叶子节点"] -->|"拿到主键 id"| A2["聚簇索引<br/>再次定位"]
A2 -->|"随机 IO"| A3["完整行数据"]
end
subgraph "覆盖索引路径（Index Only Scan）"
B1["二级索引<br/>叶子节点"] -->|"所有列都在这里"| B2["直接返回"]
end
style A1 fill:#FF9F43,color:#000
style A2 fill:#EE5A24,color:#fff
style A3 fill:#FF9F43,color:#000
style B1 fill:#00D866,color:#fff
style B2 fill:#00D866,color:#fff
[!QUESTION] 为什么避免回表这么重要？ 回表是随机 IO，而顺序 IO 和随机 IO 的性能差距是 百倍到千倍 级别（机械磁盘尤其明显，SSD 也有 10~50 倍差距）。 当匹配行数较多时，覆盖索引的收益会非常显著。
CREATE TABLE users (
id BIGINT PRIMARY KEY,
email VARCHAR(255),
name VARCHAR(100),
age INT,
INDEX idx_email(email)
);
-- ❌ 必须回表：email 在索引里，但 name 不在
SELECT name, email FROM users WHERE email = 'test@example.com';
-- ① 走 idx_email 找到 id → ② 回聚簇索引拿 name（随机 IO）
-- ✅ 覆盖索引：不需要回表！
SELECT email FROM users WHERE email = 'test@example.com';
-- 只需从 idx_email 叶子节点直接拿到 email，零回表
用联合索引构造覆盖索引
实际业务中，单列索引很难做到覆盖——查询通常需要多个字段。更常见的做法是通过联合索引把查询涉及的列"包"进去：
-- 高频查询：根据 user_id 查该用户已完成的订单金额
SELECT order_id, amount
FROM orders
WHERE user_id = 100 AND status = 'paid';
-- 方案 A：索引只有 (user_id) → 必须回表拿 status、order_id、amount
-- 方案 B：联合索引 (user_id, status, order_id, amount)
-- 叶子节点存了全部所需列 → 零回表 ✅
ALTER TABLE orders ADD INDEX idx_user_cover(user_id, status, order_id, amount);
[!NOTE] 设计覆盖索引的思路
- 先看高频查询：
SELECT了哪些列？WHERE和ORDER BY涉及哪些列？- 把 WHERE + ORDER BY + SELECT 涉及的列按合理顺序放入联合索引
- 等值列在前、范围列在后（最左前缀原则），
SELECT中无法参与过滤的列放最后代价是索引更宽、占用更多空间、写入维护成本更高——需要权衡。
[!NOTE] EXPLAIN 中怎么判断覆盖索引？
Extra = Using index→ 完整覆盖，零回表Extra = Using index condition→ 索引下推（ICP），部分过滤在索引层面完成，但仍需回表- Extra 中没有
Using index→ 触发了回表💡 更多细节（回表代价、ICP 原理、空间对比）详见 hhs/MySQL/03-索引与查询优化/13-聚簇索引与二级索引
聚簇索引 vs 二级索引
这是本节最重要的概念延伸，也是理解后续所有索引优化的基础。
flowchart TB
subgraph "聚簇索引 = 数据本身"
C1["id=1 · 整行数据"]
C2["id=2 · 整行数据"]
C3["id=3 · 整行数据"]
end
subgraph "二级索引 idx_email"
S1["email='a' → id=1"]
S2["email='b' → id=2"]
S3["email='c' → id=3"]
end
S1 -.回表.-> C1
S2 -.回表.-> C2
S3 -.回表.-> C3
style C1 fill:#00D866,color:#fff
style C2 fill:#00D866,color:#fff
style C3 fill:#00D866,color:#fff
style S1 fill:#FF9F43,color:#000
style S2 fill:#FF9F43,color:#000
style S3 fill:#FF9F43,color:#000
[!QUESTION] 什么是回表？ 当用二级索引
idx_email查WHERE email = 'a'时：
- 先在二级索引中找到
email='a'→ 得到主键id=1- 再用
id=1去聚簇索引中查找完整行数据 这个两步过程叫回表（Table Lookup）。优化方向：让查询条件直接走聚簇索引，或者用 Covering Index 避免回表。
MySQL 索引类型总览
在 B+ Tree 的基础上，InnoDB 支持多种索引类型。理解它们的选择时机也是面试和实战的常考点。
| 索引类型 | 底层结构 | 适用场景 | 等值查找 | 范围查找 | 是否有序 |
|---|---|---|---|---|---|
| 聚簇索引 (Clustered) | B+ Tree 叶子存整行数据 | 主键查询（默认自带） | ✅ O(log n) | ✅ 顺序扫描叶子 | ✅ |
| 二级索引 (Secondary) | B+ Tree 叶子存 索引列 + 主键 |
非主键字段查询 | ✅ O(log n) | ✅ | ✅ |
| 联合索引 (Composite) | 单个 B+ Tree，多列组合排序 | 前缀匹配的多字段过滤 | ✅ | ✅ | ✅ |
| 唯一索引 (Unique) | 基于 B+ Tree 加约束 | 保证列值唯一（如手机号） | ✅ | ✅ | ✅ |
| 前缀索引 (Prefix) | B+ Tree 只取字符前 N 位 | 长字符串字段（如 URL） | ✅ | ⚠️ 精度降低 | ✅ |
| 全文索引 (Fulltext) | InnoDB 使用倒排索引 | 文本搜索 (MATCH...AGAINST) |
— | — | ❌ |
| 空间索引 (Spatial) | R-Tree | GIS 地理空间数据 | — | — | ❌ |
[!NOTE] 重点记忆 除 全文索引 和 空间索引 外，其余全部依赖 B+ Tree。所以本文的核心内容覆盖了 InnoDB 90% 以上的日常使用场景。
联合索引的最左前缀原则
联合索引 (a, b, c) 的本质是：先按 a 排序，a 相同时按 b 排序，a、b 都相同时按 c 排序。
graph TD
subgraph "B+ Tree 叶子节点中数据的实际存储顺序"
R1["(10, 'pending')"]
R2["(10, 'paid')"]
R3["(10, 'shipped')"]
R4["(20, 'pending')"]
R5["(20, 'paid')"]
R6["(30, 'pending')"]
end
Q1["WHERE user_id = 10<br/>✅ 精确匹配一层"] --> S1["命中: R1, R2, R3"]
Q2["WHERE user_id = 10 AND status = 'paid'<br/>✅ 精确匹配两层"] --> S2["命中: R2"]
Q3["WHERE status = 'paid'<br/>❌ 缺少最左列 user_id"] --> S3["全表扫描"]
Q4["WHERE user_id = 10 AND created_at > ...<br/>⚠️ 只能用到 user_id"] --> S4["R1,R2,R3 + 逐行过滤"]
style S1 fill:#00D866,color:#fff
style S2 fill:#00D866,color:#fff
style S3 fill:#EE5A24,color:#fff
style S4 fill:#FF9F43,color:#000
[!NOTE] 核心直觉
- 联合索引的 B+ Tree 不是按列独立排序的，而是把所有列拼成一条记录整体排序。
- 跳过最左列 → 相当于跳过了目录的第一层，直接翻到第二层找，找不到就退化全表扫描。
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id INT,
status VARCHAR(20),
created_at DATETIME,
INDEX idx_user_status(user_id, status) -- 联合索引
);
-- 以下可以命中索引
SELECT * FROM orders WHERE user_id = 1; -- ✅ (user_id)
SELECT * FROM orders WHERE user_id = 1 AND status = 'paid'; -- ✅ (user_id, status)
-- 以下无法完全命中联合索引
SELECT * FROM orders WHERE status = 'paid'; -- ❌ 缺少最左列 user_id
SELECT * FROM orders WHERE user_id = 1 AND created_at > ...; -- ⚠️ 只能用到 user_id
[!TIP] 设计联合索引的黄金法则
- 把区分度最高的列放在最左边——能最大程度缩小搜索范围
- 等值匹配的列排在范围查询之前
- 覆盖最常出现的查询模式，而不是把所有可能的列堆在一起
实战常见陷阱：索引为什么不生效？
B+ Tree 再优秀，也用不好 SQL。以下是最常见的索引失效场景：
1. 函数 / 运算包裹了索引列
-- ❌ 索引失效 —— 每行都要计算 DATE(created_at)
SELECT * FROM orders WHERE DATE(created_at) = '2025-05-01';
-- ✅ 改用范围查询，利用 B+ Tree 的范围扫描能力
SELECT * FROM orders
WHERE created_at >= '2025-05-01 00:00:00'
AND created_at < '2025-05-02 00:00:00';
[!NOTE] 原理 B+ Tree 按原始值排序，对
created_at建了索引但查的是DATE(created_at)，相当于换了个"钥匙"去找"锁"，树根目录里根本找不到这个新钥匙。
2. LIKE 以通配符开头
-- ❌ 走全表扫描
SELECT * FROM users WHERE name LIKE '%abc%';
-- ✅ 前缀匹配仍然走索引
SELECT * FROM users WHERE name LIKE 'abc%';
3. OR 条件中有一列无索引
-- ❌ 即使 id 有索引、email 也有索引，但一旦 email 没索引，整个 OR 就可能不走索引
SELECT * FROM users WHERE id = 1 OR email = 'test@x.com';
4. 隐式类型转换
-- 假设 phone 是 VARCHAR 类型并建有索引
-- ❌ 传入的是数字类型，MySQL 要对每行做 CAST(phone AS SIGNED)
SELECT * FROM users WHERE phone = 13800138000;
-- ✅ 保持类型一致
SELECT * FROM users WHERE phone = '13800138000';
5. 回表太多导致 Optimizer 选择全表扫描
-- 当二级索引需要回表的行数占总行数很大比例时（通常 > 20%~30%），
-- Optimizer 会认为走索引反而更慢（频繁随机 IO），主动选择全表扫描。
-- 这是正常行为，强行用 FORCE INDEX 往往适得其反。
[!TIP] 怎么判断要不要加索引？
- 先用
EXPLAIN看执行计划type从ALL → index → range → ref → const依次越来越优- 如果已经是
ref或range且 Extra 没有异常提示，说明索引已经在工作
索引的设计权衡
好索引带来快查询，但也带来慢写入。设计时需要权衡以下代价：
写入放大（Write Amplification）
聚簇索引只需维护一个 B+ Tree，但每个二级索引都是独立的 B+ Tree。每插入一行数据：
INSERT INTO users (id, email, name, age) VALUES (1, 'a@x.com', 'Tom', 25);
-- InnoDB 需要同时更新：
-- ① 聚簇索引 idx__PRIMARY → 1 次 IO（顺序插入在末尾）
-- ② 二级索引 idx_email → 1 次 IO（定位 + 可能的页分裂）
-- ③ 每多一个二级索引 → 各加 1 次 IO
-- 总写入成本 = 1（聚簇）+ N（N 个二级索引）
[!NOTE] 直观理解 假设有 5 个二级索引，插入一条记录就要写 6 棵 B+ Tree。 删除、更新同理——所有相关索引都要同步修改。这就是为什么索引越多，写越慢。
空间占用
-- 一张表 100 GB，建了 4 个二级索引：
-- 聚簇索引 ≈ 100 GB（就是数据本身）
-- 二级索引 × 4 ≈ 30~50 GB（取决于索引列的宽度）
-- 总磁盘用量 ≈ 130~150 GB
[!QUESTION] 思考一下 如果你有一张日增百万行的日志表，你会给它建几个二级索引？ ——答案通常是：少而精。先分析最慢的几个查询，针对性加索引，而不是"以防万一全加上"。
维护开销
| 操作 | 聚簇索引影响 | 二级索引影响 |
|---|---|---|
| INSERT | 叶子节点末尾追加（顺序 IO） | 需定位正确位置 + 可能的页分裂（随机 IO） |
| UPDATE | 若主键不变则无影响；变化则删除+重建 | 所有涉及列变化的索引都需要更新 |
| DELETE | 标记删除或合并页 | 同上，且可能有页合并开销 |
| 页分裂 | 顺序写满一页后可能触发 | 频率更高（写入定位分散 + 热点行密集） |
[!TIP] 经验法则
- 写密集型系统（如日志、订单创建），索引数量控制在 3 个以内
- 读密集型系统（如报表查询），可以放宽到 5 个左右
- 超过 10 个索引几乎必然影响写入性能，应审慎评估
最佳实践清单
结合上述原理与实战经验，整理一份日常工作中可以直接使用的检查清单：
[!CHECKLIST] 索引设计与审查清单
[建表阶段]
- 主键选择合理（自增 BIGINT / UUID 替代方案考虑过？）
- 高频查询字段已建索引
- 联合索引区分度最高的列放在最左
- 避免过度索引（写多读少的表控制在 3 个以内）
[上线前]
- 所有慢查询
EXPLAIN后 type 不是ALL- 覆盖索引场景用
Using index确认不走回表- 范围查询列不要和其他等值列反序排列
- VARCHAR 长字符串考虑使用前缀索引
[线上巡检]
SHOW INDEXES检查 Cardinality 接近行数- 无用索引定期清理（使用 pt-duplicate-key-checker 等工具）
- 大表 DDL 使用
ALGORITHM=INPLACE, LOCK=NONE避免锁表- 监控慢查询日志，按需调整索引策略
关联笔记
- hhs/GORM/02-模型定义 — GORM 创建索引的 struct tag 映射到 B+ Tree
- hhs/MySQL/03-索引与查询优化/13-聚簇索引与二级索引 — 深入解析聚簇索引的物理存储结构与二级索引的回表优化
- hhs/MySQL/03-索引与查询优化/14-联合索引与最左前缀 — 联合索引的设计原则与实践
- hhs/MySQL/03-索引与查询优化/15-EXPLAIN 完全指南 — type=index / range 的物理含义与索引执行计划解读