当前位置：首页 > news >正文

InnoDB索引结构与排序构建机制详解

news 2025/9/19 10:52:07

这段内容深入讲解了 InnoDB 存储引擎中索引的物理结构（17.6.2.2）和排序索引构建机制（17.6.2.3），是理解 MySQL 性能优化、索引创建效率以及存储行为的关键知识。我们可以分两大部分来系统性地理解：

一、InnoDB 索引的物理结构（Physical Structure of an InnoDB Index）

1. 索引的数据结构：B-tree 和 R-tree

普通索引（非空间索引）使用 B-tree 结构
- B-tree 是一种自平衡的多路搜索树，适合磁盘 I/O 操作。
- 所有数据记录都存储在叶子节点上（即“B+树”结构）。
空间索引（如地理坐标）使用 R-tree
- R-tree 专为多维数据设计，比如经纬度范围查询。

✅ 提示：我们平时说的 InnoDB “B-tree 索引”，其实更准确地说是 B+树 —— 只有叶子节点存数据，非叶子节点只存指针和键值。

2. 页大小（Page Size）

默认页大小为 16KB。
这个值由启动时的 innodb_page_size 配置决定，初始化后不可更改。
每个索引页最多存放一定数量的索引记录，取决于记录大小。

3. 插入策略与页填充率

场景	页填充情况
顺序插入（如自增主键）	页面约填满到 `15/16`（保留 1/16 空间供后续更新）
随机插入	页面填充程度较低，约为 `1/2 ~ 15/16`

📌 原因：InnoDB 主动预留一部分空间（约 6.25%），用于未来修改或插入，避免频繁页分裂。

4. `innodb_fill_factor` 参数的作用

控制排序建索引（Sorted Index Build）过程中每页的填充比例。
例如：
- innodb_fill_factor=80 → 每页只填 80%，留 20% 给将来增长；
- innodb_fill_factor=100 → 实际仍会保留约 1/16 的空闲空间（历史兼容行为）。
⚠️ 注意：这不是硬性限制，而是一个“提示”（hint），实际可能略有偏差。
❗ 不适用于 TEXT/BLOB 外部页。

5. MERGE_THRESHOLD：页合并阈值

默认值：50%
含义：当某个索引页的使用率低于这个百分比时，InnoDB 会尝试将它与相邻页合并，以节省空间。
应用于 B-tree 和 R-tree。
目的：防止大量删除或更新导致碎片化。

🔁 类似“垃圾回收”机制，保持 B-tree 结构紧凑高效。

二、排序索引构建（Sorted Index Builds）

这是现代 InnoDB 中创建或重建索引的高性能方式，取代了旧式的逐条插入方法。

为什么需要“排序建索引”？

传统方式的问题：

一条一条插入索引记录；
每次都要查找插入位置（打开游标）、可能发生页分裂；
效率低、I/O 多、容易产生碎片。

👉 新方法：“批量加载 + 排序 + 一次性写入”，效率更高！

排序建索引的三个阶段

第一阶段：扫描聚簇索引并生成排序数据

扫描表的聚集索引（保证行有序）；
为每个二级索引提取对应的 (索引列, 主键) 条目；
将这些条目放入内存中的排序缓冲区（sort buffer）；
缓冲区满后，进行内部排序，并写入临时文件 → 称为一个“run”。

💡 类似外部排序（External Sort）

第二阶段：归并排序（Merge Sort）

如果有多个 run 文件，执行多路归并排序，得到完全有序的索引条目流。

第三阶段：按序插入 B-tree

使用“自底向上”（bottom-up）的方式构造 B-tree；
关键点：始终持有最右边叶子页的引用（right-most leaf page），新记录直接追加；
当前页满了？→ 分配兄弟页，父节点添加指针，释放旧页锁；
自动向上扩展，直到根节点。

✅ 优势：避免反复查找插入位置和频繁的悲观分裂操作。

排序建索引的优势 vs 老方法

对比项	老方法（Top-down）	新方法（Bottom-up，Sorted Build）
插入方式	逐条插入	批量排序后集中插入
是否需查找位置	是（每次开游标）	否（已排序，知道该往哪插）
页分裂频率	高（常发生乐观/悲观分裂）	低（连续分配，减少分裂）
性能	差（CPU、I/O 高）	好（速度快很多）
碎片	多	少

特殊场景支持情况

✅ 支持排序建索引的情况：

普通二级索引
全文索引（Full-text Index）
- 曾经用 SQL 插入，现在也改用排序构建，更快。
压缩表（Compressed Tables）
- 新方法更优：先在未压缩页中累积记录；
- 满了再尝试压缩；
- 若失败则分裂并重试（配合自适应 padding 提高压缩成功率）；

❌ 不支持的情况：

空间索引（Spatial Indexes）
- 因为其底层是 R-tree，不支持这种批量构建模式。

其他重要特性

🔇 Redo 日志关闭

在排序建索引期间，redo logging 被禁用（为了性能）；
但通过检查点（checkpoint）机制确保崩溃恢复安全：
- 定期强制刷脏页到磁盘；
- Page Cleaner 线程被频繁唤醒，提前刷出脏页，减轻 checkpoint 压力；
- 实现 I/O 与 CPU 并行处理。

📊 优化器统计信息可能不同

因为索引构建算法变了，页分布、聚集程度等可能略有差异；
导致 ANALYZE TABLE 产生的统计信息与老方法不同；
但官方认为这不会显著影响执行计划性能。

总结图解：排序建索引流程

[阶段1] 聚集索引扫描↓生成 (key, pk) 对↓排序缓冲区（Sort Buffer）↓ 满了就写临时文件 Run1, Run2...↓
[阶段2] 归并排序（Merge Sort）↓得到全局有序序列↓
[阶段3] Bottom-up 构造 B-tree↓追加到右下角叶子页↓满了就分页、升层 → 最终形成完整索引