MySQL innodb b-tree在后台重新平衡异步或在需要重新平衡时完成每次写入操作

Question

我只是好奇mysql何时在需要时执行重平衡操作。

谢谢。

Answer 1

如果索引是唯一的键或主键，InnoDB必须同步更新B树(在插入/更新/删除时)。

否则，对于非唯一索引，更改将写入InnoDB变化缓冲器。这些补充索引的B树。

这些更改将合并到B树中，或者在下次查询读取这些索引项时合并，或者最终由一个“合并线程”合并。此外，InnoDB有一个“慢速关闭”选项，它在关闭MySQL服务器时完全合并所有挂起的更改缓冲区条目。

Answer 2

“再平衡”和“碎片整理”是密切相关的。对于这个答案，我将交替使用这些术语。

InnoDB从不自动重新平衡整个BTree。

InnoDB在存储“脏”块时，可能会将该块与相邻块合并，从而进行少量的再平衡。其他线程的锁可能会阻塞这些块，从而推迟操作。

InnoDB“从不”需要完全的再平衡；它的BTrees对于大多数用法来说是“足够平衡的”。此外，与成本相比，完全再分割的好处微乎其微。在过去，它是数据BTree和/或索引BTree的完整副本。更新的ALTER“算法”可以实现INPLACE (或其他什么)。如果您坚持再平衡，请提供之前和之后的统计数字，以证明您得到了多少好处。

删除一个表的大部分是缓慢的，使表变得相当零碎。通常比较好的做法是复制要保存的行。这就产生了“免费”去碎片的效果。而且跑得更快。关于“大”删除的更多信息：http://mysql.rjweb.org/doc.php/deletebig

可以说，InnoDB的BTrees从来都不是“不平衡”的，因为我认为树的深度是恒定的。但是，任何块都可能变得不够满。当非叶节点变小时，BTree就会“倾斜”.因此，你可能会认为这种“碎片化”会导致“不平衡”？

"change“将非UNIQUE索引更新排队等待‘延迟’写入。这允许更有效地进行索引更新，从而在一定程度上有利于BTree的本地化清理。