OPTIMIZE TABLE makes tables grow

MySQL 26.10.0 includes the following change, dated September 2026: BUG#27362028: "INPLACE" TABLE REBUILD CREATES MUCH LARGER IBD FILE THAN "COPY" REBUILD, which is applicable to their implementation of parallel index creation; MariaDB Server did not implement MDEV-16281 yet.

In MySQL 5.7 and MariaDB Server the MySQL 26.10.0 function Page_load::init() is equivalent to PageBulk::init(). The essential part of the fix is that btr_page_alloc() is being invoked with a meaningful hint_page_no, to address the following:

The file-segment allocator uses directional allocation and page hints to improve physical page locality. When the segment's free-page ratio is below innodb_segment_reserve_factor, FSP_UP may assign a new extent instead of reusing free pages in existing extents. The threshold limits how much existing free space may be bypassed for this optimization.

With a meaningful hint, subsequent allocations can continue in the new extent, placing logical sibling pages close together. The COPY rebuild path provides such hints while splitting its rightmost leaf page.

The sorted DDL builder instead always passed page 0 as the allocation hint. After FSP_UP assigned a new extent, subsequent allocations were not directed back to it and could use older non-full extents instead. Repeating this process left many newly assigned extents mostly unused and inflated the resulting .ibd file.

In MariaDB Server, MDEV-26740 took a different approach: removing a call to fsp_reserve_free_extents() right before the call to btr_page_alloc() so that the file will only be extended if it is absolutely necessary. While this did reduce the growth of the files, it did not completely remove the difference. Passing suitable allocation hint page numbers does.

Note: MariaDB is missing a parameter innodb_segment_reserve_factor (MySQL WL#14521), which the MySQL test is also using.