«Перебалансировка» и «дефрагментация» тесно связаны. Для этого ответа я буду использовать термины взаимозаменяемо.
InnoDB никогда автоматически не перебалансирует весь BTree.
InnoDB при хранении «грязного» блока, может объединить этот один блок со смежным блоком, что приведет к небольшому изменению баланса. Блокировки другими потоками могут блокировать взаимодействие с этими блоками, тем самым откладывая действие.
InnoDB "никогда" не нуждается в полной перебалансировке; его BTrees "достаточно сбалансированы" для большинства видов использования. Кроме того, выгода от полной рефрагментации ничтожна по сравнению со стоимостью. В прошлом это была полная копия данных BTree и / или индекса BTree. Более новые ALTER «алгоритмы» могут сделать это INPLACE (или что угодно). Если вы настаиваете на перебалансировке, предоставьте статистику до и после, чтобы продемонстрировать, какую выгоду вы получаете.
Удаление большей части таблицы происходит медленно и оставляет таблицу довольно фрагментированной. Обычно лучше скопировать строки в keep . Это имеет эффект дефрагментации "бесплатно". И это работает быстрее. Больше о «большом» удалении: http://mysql.rjweb.org/doc.php/deletebig
Возможно, BTree InnoDB никогда не являются «несбалансированными» в том смысле, что глубина (я думаю) постоянна по всему дереву. Однако любой блок может стать менее чем полным. Когда неконечные узлы становятся менее заполненными, это наклоняет BTree. Следовательно, вы можете утверждать, что эта «фрагментация» вызывает «дисбаланс»?
«Буфер изменений» ставит в очередь обновления не-1028 * индекса для «отложенной» записи. Это позволяет более эффективно выполнять обновления индекса, что в некоторой степени выгодно для любой локальной очистки BTree.