使用OPTIMIZE进行Mariadb表碎片整理

Question

我们正在运行MariaDB v 10.1.30，测试脚本以运行数据库维护脚本，使用OPTIMIZE TABLE命令对表进行碎片整理和重建索引，方法是使用设置innodb_defragment = 1的新10.1.1补丁。

我已经使用Alogorithm = INPLACE测试了Alter Table，工作正常，但我正在尝试使用innodb_defragment并使用optimize来避免在使用Alter table INPLACE算法重建表时创建临时文件。

在使用Optimize时，没有创建临时表，但是表被锁定不允许并发连接，而​​Alter Table with Alogorithm = INPLACE不是这种情况，但文档提到优化是使用INPLACE算法完成的。

https://mariadb.org/defragmenting-unused-space-on-innodb-tablespace/

这是一个错误还是我在这里遗漏了一些东西，请告知。

Answer 1

速度的好处几乎为零。

• “点查询”（您可以在其中找到关键字并可以直接转到该行）取决于BTree的深度。对于一百万行，深度将约为3。对于万亿行，约为6。优化表不太可能缩小深度。

• “范围扫描”（BETWEEN，>等）跨过一个块，看着每一行。然后，它跳（通过链接）到下一个块，直到找到所需的所有行。当然，您会在未优化的表格中触摸更多的块，但是大部分的工作是访问每一行。

空间的好处是有限的。

• INSERT可能会添加到非完整块，也可能会将完整块分成两个半完整块。之后，两个相邻的，有些空的块将合并在一起。因此，BTree会自然地趋向于 average 块已满69％的状态。也就是说，OPTIMIZE TABLE对 space 的好处是有限的。

• 用不同的措词，OPTIMIZE可以将表的磁盘占用空间缩小到原来的69％，但是后续操作将再次增加表的容量。

• 如果使用的是innodb_file_per_table=OFF，则OPTIMIZE无法将可用块返回给操作系统。这样的块可以在将来的INSERTs中重用。

OPTIMIZE TABLE是入侵。

• 它将表复制过来，并在此过程中将其锁定。对于需要100％正常运行时间的网站，这是不可接受的。

• 如果您正在使用复制，则后续的写操作可能会堆积在OPTIMIZE之后，从而使从设备无法及时更新。

大删除次数

• 删除许多行后，OPTIMIZE可能会受益，但请检查69％的估计值。

• 如果经常发生大删除，则可能还需要执行其他操作。参见http://mysql.rjweb.org/doc.php/deletebig

历史和内部信息

• 旧版本以一种简单的方式完成了OPTIMIZE：创建一个新表（相同的模式）；将行复制到其中：重命名表；下降。不允许写信。
• ALGORITHM=INPLACE 可能锁定几个块，将它们组合起来以填满一个块，然后向前滑动。这需要一定程度的锁定。基于问题，听起来像只是锁定了整个表。
• 请注意，可以分别“优化”每个BTree（PK + Data或二级索引）。但是没有命令允许仅对主BTree（PK + data）执行此操作。可以通过DROP INDEX + ADD INDEX来优化单个 secondary 索引，但这会丢失索引。而是考虑做NOCOPY ADD INDEX，然后然后 INSTANT DROP INDEX。警告：如果使用USE_INDEX或FORCE INDEX，可能会造成影响。

（注意：此答案适用于InnoDB，不适用于MyISAM。）