MySQL innodb b-tree rebalance async in background or finish on per write operation if rebalance is needed

Question

I just curious about when mysql innodb execute rebalance operation when it is needed.

Thanks.

Answer 1

InnoDB must update a B-tree synchronously (at the time of your INSERT/UPDATE/DELETE) if the index is a UNIQUE KEY or PRIMARY KEY.

Otherwise, for non-unique indexes, the changes are written to the InnoDB change buffer . These supplement the B-tree for the index.

The changes are merged into the B-tree either the next time someone's query reads those index entries, or else they are merged eventually by a "merge thread." Also InnoDB has a "slow shutdown" option which fully merges all pending change buffer entries at the time you shut down MySQL Server.

Answer 2

"Rebalancing" and "defragmenting" are closely related. For this Answer, I will use the terms interchangeably.

InnoDB never automatically rebalances the entire BTree.

InnoDB, when storing a 'dirty' block, may merge that one block with an adjacent block, thereby doing a tiny bit of rebalancing. Locks by other threads may block messing with those blocks, thereby postponing the action.

InnoDB "never" needs a full rebalancing; its BTrees are "balanced enough" for most usages. Furthermore, the benefit from a full refragmentation is minuscule compared to the cost. In the past, it was a full copy of the data BTree and/or index BTree. Newer ALTER "algorithms" can do it INPLACE (or whatever). If you insist on rebalancing, please provide before and after statistics to demonstrate how much benefit you get.

Deleting most of a table is slow and leaves the table rather fragmented. It is usually better to copy over the rows to keep . This has the effect of defragmenting "for free". And it runs faster. More on 'big' deletes: http://mysql.rjweb.org/doc.php/deletebig

Arguably, InnoDB's BTrees are never "unbalanced" in that the depth is [I think] constant across the tree. However, any block may become less than full. When non-leaf nodes become less than full, that 'tilts' the BTree. Hence, you could argue that this "fragmentation" causes "unbalance"?

The "change buffer" queues up non- UNIQUE index updates for 'delayed' writing. This allows index updates to be done more efficiently, thereby somewhat benefitting any localized cleanup of the BTree.