InnoDB 在创建或重建索引时执行批量加载，而不是逐个插入索引记录。这也称为有序索引构建。有序索引构建不支持空间索引。

索引构建有三个阶段。在第一阶段，聚簇索引 被扫描，索引条目被生成并添加到排序缓冲区中。当 排序缓冲区 满时，条目被排序并写入临时中间文件。这也称为一个 “运行”。在第二阶段，一个或多个运行被写入临时中间文件，然后对文件中的所有条目执行合并排序。在第三和最后一个阶段，排序后的条目被插入到 B 树 中；这个最后阶段是多线程的。

在引入有序索引构建之前，索引条目是使用插入 API 一个记录一个记录地插入到 B 树中的。这方法涉及打开 B 树 游标 以查找插入位置，然后使用 乐观 插入将条目插入 B 树页面。如果插入失败，因为页面已满，则执行 悲观 插入，这涉及打开 B 树游标并分割和合并 B 树节点以找到空间以容纳条目。

有序索引构建使用 “自下而上” 方法来构建索引。使用这种方法，在 B 树的所有级别上都持有右侧叶页的引用。右侧叶页在必要的 B 树深度上被分配，并根据排序顺序插入条目。一旦叶页满了，节点指针被追加到父页，并为下一个插入分配了一个新的叶页。这过程继续，直到所有条目被插入，可能会导致插入到根级别。当一个叶页被分配时，之前固定叶页的引用被释放，新的叶页变成了右侧叶页和新的默认插入位置。

为未来索引增长预留 B 树页面空间

要为未来索引增长预留空间，可以使用 innodb_fill_factor 变量来预留 B 树页面的百分比空间。例如，将 innodb_fill_factor 设置为 80 将预留 20% 的空间在 B 树页面中。这设置适用于 B 树叶页和非叶页，不适用于外部页面用于 TEXT 或 BLOB 条目。预留的空间量可能不完全按照配置，因为 innodb_fill_factor 值被解释为提示而不是硬限制。

有序索引构建和全文索引支持

有序索引构建支持 全文索引。以前，SQL 用于将条目插入全文索引。

有序索引构建和压缩表

对于 压缩表，以前的索引创建方法将条目追加到压缩和未压缩页面上。当修改日志（表示压缩页面上的空闲空间）变满时，压缩页面将被重新压缩。如果压缩失败，因为空间不足，则页面将被分割。使用有序索引构建，条目仅追加到未压缩页面上。当未压缩页面变满时，它将被压缩。自适应填充用于确保压缩在大多数情况下成功，但如果压缩失败，则页面将被分割，并尝试重新压缩。这过程继续，直到压缩成功。有关 B 树页面压缩的更多信息，请参阅 第 17.9.1.5 节，“InnoDB 表的压缩工作原理”。

有序索引构建和重做日志记录

重做日志 在排序索引构建期间被禁用。相反，有一个 检查点，以确保索引构建可以抵御意外退出或故障。检查点强制将所有脏页写入磁盘。在排序索引构建期间，页清洁器 线程会定期被信号，以便刷新 脏页，以确保检查点操作可以快速处理。通常，页清洁器线程在干净页数量下降到某个阈值以下时刷新脏页。对于排序索引构建，脏页会被及时刷新，以减少检查点开销并并行化 I/O 和 CPU 活动。

排序索引构建和优化器统计信息

排序索引构建可能会生成与之前索引创建方法生成的不同 优化器 统计信息。统计信息的差异，不会影响工作负载性能，是由于用于填充索引的不同算法所致。