InnoDB 使用批量加载方式而不是逐个插入索引记录，当创建或重建索引时。这种索引创建方法也称为排序索引构建。排序索引构建不支持空间索引。

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

在排序索引构建引入之前，索引条目使用插入API逐个插入到B树中。这方法涉及到打开B树游标以找到插入位置，然后使用乐观插入将条目插入到B树页中。如果插入失败，因为页面已满，一个悲观插入将被执行，这涉及到打开B树游标并将B树节点分割和合并以找到空间插入条目。这个“top-down”方法构建索引的缺点是搜索插入位置的成本和不断分割和合并B树节点的成本。

排序索引构建使用“bottom-up”方法构建索引。这个方法中，B树的右叶节点在所有B树深度上保持一个引用。必要的B树深度的右叶节点被分配，然后条目根据排序顺序插入。直到所有条目插入完成，这可能会导致到根级别的插入。每当分配一个叶节点时，之前固定叶节点的引用将被释放，新的分配叶节点变为右叶节点和新的默认插入位置。

为了预留未来的索引增长空间，您可以使用innodb_fill_factor变量来保留B树页的百分比空间。例如，将innodb_fill_factor设置为80将保留B树页的20%空间用于排序索引构建。这设置适用于B树叶和非叶页，但不适用于用于TEXT或BLOB条目的外部页。保留的空间量可能不准确，因为innodb_fill_factor值被解释为提示而不是硬限制。

排序索引构建 and Full-Text Index Support

支持对全文索引的排序索引构建。之前，SQL用于将条目插入全文索引。

Sorted Index Builds and Compressed 表

对于压缩表，之前的索引创建方法将条目追加到压缩和未压缩页上。当修改日志（表示压缩页上的自由空间）满时，压缩页将被重新压缩。如果压缩失败由于缺乏空间，页将被分割。使用排序索引构建时，条目只追加到未压缩页上。当未压缩页满时，它将被压缩。自适应填充用于确保压缩成功，但如果压缩失败，页将被分割并再次压缩。这过程将继续直到压缩成功。关于B树页压缩的更多信息，请见第17.9.1.5节，“InnoDB表的压缩工作”。

排序索引构建 and Redo Logging

redo日志在排序索引构建期间禁用。相反，有检查点以确保索引构建可以在意外退出或失败时恢复。检查点强制将所有脏页写入磁盘。 durante排序索引构建期间，页面清洁线程将定期被信号以flush脏页，以确保检查点操作可以快速处理。通常，页面清洁线程将脏页flush到磁盘上。当脏页数量低于设置的阈值时，页面清洁线程将flush脏页。对于排序索引构建，脏页将被flush到磁盘上，以减少检查点开销和并行I/O和CPU活动。

Sorted Index Builds and 优化器统计

排序索引构建可能会导致优化器统计数据与之前的索引创建方法不同。统计数据的差异不太可能影响工作负载性能，这是由于使用的不同算法来填充索引。