#### 15.6.2.3 Sorted Index Builds

[]()[]()

`InnoDB` performs a bulk load instead of inserting one index record at a time when creating or rebuilding indexes. This method of index creation is also known as a sorted index build. Sorted index builds are not supported for spatial indexes.

 There are three phases to an index build. In the first phase, the [clustered index](glossary.html#glos_clustered_index) is scanned, and index entries are generated and added to the sort buffer. When the [sort buffer](glossary.html#glos_sort_buffer) becomes full, entries are sorted and written out to a temporary intermediate file. This process is also known as a “run”. In the second phase, with one or more runs written to the temporary intermediate file, a merge sort is performed on all entries in the file. In the third and final phase, the sorted entries are inserted into the [B-tree](glossary.html#glos_b_tree).

 Prior to the introduction of sorted index builds, index entries were inserted into the B-tree one record at a time using insert APIs. This method involved opening a B-tree [cursor](glossary.html#glos_cursor) to find the insert position and then inserting entries into a B-tree page using an [optimistic](glossary.html#glos_optimistic) insert. If an insert failed due to a page being full, a [pessimistic](glossary.html#glos_pessimistic) insert would be performed, which involves opening a B-tree cursor and splitting and merging B-tree nodes as necessary to find space for the entry. The drawbacks of this “top-down” method of building an index are the cost of searching for an insert position and the constant splitting and merging of B-tree nodes.

 Sorted index builds use a “bottom-up” approach to building an index. With this approach, a reference to the right-most leaf page is held at all levels of the B-tree. The right-most leaf page at the necessary B-tree depth is allocated and entries are inserted according to their sorted order. Once a leaf page is full, a node pointer is appended to the parent page and a sibling leaf page is allocated for the next insert. This process continues until all entries are inserted, which may result in inserts up to the root level. When a sibling page is allocated, the reference to the previously pinned leaf page is released, and the newly allocated leaf page becomes the right-most leaf page and new default insert location.

##### Reserving B-tree Page Space for Future Index Growth

 To set aside space for future index growth, you can use the [`innodb_fill_factor`](innodb-parameters.html#sysvar_innodb_fill_factor) variable to reserve a percentage of B-tree page space. For example, setting [`innodb_fill_factor`](innodb-parameters.html#sysvar_innodb_fill_factor) to 80 reserves 20 percent of the space in B-tree pages during a sorted index build. This setting applies to both B-tree leaf and non-leaf pages. It does not apply to external pages used for [`TEXT`](blob.html) or [`BLOB`](blob.html) entries. The amount of space that is reserved may not be exactly as configured, as the [`innodb_fill_factor`](innodb-parameters.html#sysvar_innodb_fill_factor) value is interpreted as a hint rather than a hard limit.

##### Sorted Index Builds and Full-Text Index Support

 Sorted index builds are supported for [fulltext indexes](glossary.html#glos_fulltext_index). Previously, SQL was used to insert entries into a fulltext index.

##### Sorted Index Builds and Compressed Tables

 For [compressed tables](glossary.html#glos_compression), the previous index creation method appended entries to both compressed and uncompressed pages. When the modification log (representing free space on the compressed page) became full, the compressed page would be recompressed. If compression failed due to a lack of space, the page would be split. With sorted index builds, entries are only appended to uncompressed pages. When an uncompressed page becomes full, it is compressed. Adaptive padding is used to ensure that compression succeeds in most cases, but if compression fails, the page is split and compression is attempted again. This process continues until compression is successful. For more information about compression of B-Tree pages, see [Section 15.9.1.5, “How Compression Works for InnoDB Tables”](innodb-compression-internals.html).

##### Sorted Index Builds and Redo Logging

[Redo logging](glossary.html#glos_redo_log) is disabled during a sorted index build. Instead, there is a [checkpoint](glossary.html#glos_checkpoint) to ensure that the index build can withstand an unexpected exit or failure. The checkpoint forces a write of all dirty pages to disk. During a sorted index build, the [page cleaner](glossary.html#glos_page_cleaner) thread is signaled periodically to flush [dirty pages](glossary.html#glos_dirty_page) to ensure that the checkpoint operation can be processed quickly. Normally, the page cleaner thread flushes dirty pages when the number of clean pages falls below a set threshold. For sorted index builds, dirty pages are flushed promptly to reduce checkpoint overhead and to parallelize I/O and CPU activity.

##### Sorted Index Builds and Optimizer Statistics

 Sorted index builds may result in [optimizer](glossary.html#glos_optimizer) statistics that differ from those generated by the previous method of index creation. The difference in statistics, which is not expected to affect workload performance, is due to the different algorithm used to populate the index.

