使用新选项innodb=1进行MariaDB碎片整理

Question

我尝试使用innodb=1 https://mariadb.com/kb/en/library/defragmenting-innodb-tablespaces/来整理表。

但这是一次糟糕的经历：-表上锁-没有一个好的碎片整理结果(总是没有数据在表上)

所以我使用percona工具https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html

并且取得了很好的结果，没有锁，也没有更多的数据在表上自由。(但需要磁盘上的空间来复制表)

但是第一种方法有什么问题呢？

最新情况：

Answer 1

神话破坏者。

碎片整理是一个基本不适用于InnoDB的概念。很少值得使用OPTIMIZE TABLE或其他技术来整理。

InnoDB片段和/或具有“空闲”空间的方式有几种：

• 块中的行没有填满块。
• BTree块被吸引到69%完全。如果要在随机点插入新行，这是块内浪费的限制。
• “范围”中的块没有消耗整个范围。
• 撤消/重做记录暂时占用空间。
• 数据和索引都是BTrees，具有不同的“空闲”空间。

SHOW TABLE STATUS只显示了“免费”空间的一部分。此外，它通常会表明4/5/6/7 7MB对于非小型桌子是免费的，因为在“范围”内保留了空间以供将来采取行动。

为什么是碎片？

• 碎片整理只对性能有很小的好处；因此，这很少是一个有效的理由。
• 如果您几乎没有磁盘空间，碎片整理可能会使您暂时摆脱麻烦。但是，如果defrag操作需要复制表/表空间，那么您可能就没有空间去做了。接-22。好的，MariaDB的特性避免了复制。但是它是否会缩小表空间文件的大小，从而将空间还给操作系统呢？
• InnoDB已经完成了一些碎片整理--通过将相邻的一些空块自动组合起来(在某些情况下)。

(查看TABLE STATUS提供的)

它显示了0.9GB的“数据”，但却显示了一个巨大的6.9GB“免费”。(我猜想STATUS是在OPTIMIZE之后拍摄的？)这种情况可以在多种情况下存在：

• innodb_file_per_table = OFF，在这种情况下，“空闲”是ibdata1中有多少空闲空间，与表无关。(你说这不是你的案子。)
• 这张桌子有一千PARTITIONs。每个分区总是显示一些“空闲”空间；它的加起来可以达到6.9GB。( PARTITIONing不明智的原因之一就是追求。)
• 最近，您使用了DELETEd表的大部分行。这可能是一个非常缓慢的过程。创建一个新表、复制要保留的行、然后重命名以使表就位会更快。而且，你猜怎么着，这种方法会给你免费的“优化”。

根据手册，MariaDB中的碎片整理功能：

注意，表空间文件(包括ibdata1)不会因为碎片整理而收缩，但是由于使用的数据页较少，在InnoDB缓冲池中将获得更好的内存利用率。

所以..。

• 它在整理碎片时不会占用额外的磁盘空间。如果磁盘空间太低，这可能非常重要。
• 它无法将空间还给操作系统，甚至对于file_per_table也是如此。
• 它显然不会阻止在碎片整理期间对表的访问。(最坏的情况是，它会迅速爆发。)