14.6.2.3 排序索引构建

InnoDB执行大容量加载，而不是在创建或重建索引时一次插入一个索引记录。这种索引创建方法也称为排序索引构建。空间索引不支持排序索引构建。

索引构建分为三个阶段。在第一阶段，扫描clustered index，并生成索引条目并将其添加到排序缓冲区。当sort buffer变满时，将对条目进行排序并将其写到临时中间文件中。此过程也称为“运行”。在第二阶段，将一个或多个运行写入临时中间文件，对文件中的所有条目执行合并排序。在第三个也是最后一个阶段，将已排序的条目插入B-tree。

在引入排序的索引版本之前，使用插入 API 将索引条目一次插入到 B 树中的一条 Logging。此方法涉及打开 B 树cursor来找到插入位置，然后使用optimistic插入项将条目插入 B 树页面。如果由于页面已满而导致插入失败，则将执行pessimistic插入，这涉及打开 B 树游标并根据需要拆分和合并 B 树节点以找到条目空间。这种构建索引的“自顶向下”方法的缺点是搜索插入位置的成本以及 B 树节点的不断拆分和合并的成本。

排序索引的构建使用“自下而上”的方法来构建索引。通过这种方法，在 B 树的所有级别都保留了对最右边的叶子页的引用。在必要的 B 树深度处分配最右边的叶子页，并根据其排序 Sequences 插入条目。一旦叶子页已满，节点指针将附加到父页面，并且为下一个插入分配同级叶子页。此过程将一直持续到插入所有条目为止，这可能会导致插入到根级别。分配同级页面后，将释放对先前固定的叶子页面的引用，并且新分配的叶子页面将成为最右边的叶子页面和新的默认插入位置。

保留 B 树页面空间以用于将来的索引增长

要为将来的索引增长留出空间，可以使用innodb_fill_factor配置选项来保留一定比例的 B 树页面空间。例如，将innodb_fill_factor设置为 80 会在排序索引构建过程中保留 B 树页面中 20％的空间。此设置适用于 B 树叶子页面和非叶子页面。它不适用于用于TEXT或BLOB条目的外部页面。保留的空间量可能与配置的不完全一样，因为innodb_fill_factor值被解释为提示而不是硬限制。

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

fulltext indexes支持排序索引版本。以前，SQL 是用于将条目插入全文索引的。

排序索引构建和压缩 table

对于compressed tables，以前的索引创建方法将条目附加到压缩和未压缩的页面上。当修改日志(table 示压缩页面上的可用空间)已满时，将重新压缩压缩页面。如果由于空间不足而导致压缩失败，则页面将被拆分。使用排序的索引版本时，条目仅追加到未压缩的页面。当未压缩的页面已满时，它将被压缩。自适应填充用于确保大多数情况下压缩成功，但是，如果压缩失败，则将拆分页面并再次尝试压缩。该过程一直持续到压缩成功为止。有关压缩 B 树页面的更多信息，请参见第 14.9.1.5 节“ InnoDBtable 的压缩方式”。

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

Redo logging在排序索引构建期间被禁用。而是使用checkpoint来确保索引构建可以承受崩溃或失败。该检查点强制将所有脏页写入磁盘。在排序索引构建过程中，会定期向page cleaner线程发送 signal 以刷新dirty pages，以确保可以快速处理检查点操作。通常，当清除页数低于设置的阈值时，页面清除程序线程将刷新脏页。对于排序的索引生成，脏页将立即刷新，以减少检查点开销并并行化 I/O 和 CPU 活动。

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

排序的索引构建可能会导致optimizer统计信息与以前的索引创建方法所生成的统计信息不同。统计信息的差异(预计不会影响工作负载性能)是由于用于填充索引的算法不同。