Mariadb 表碎片整理使用 OPTIMIZE答案

【问题标题】：Mariadb table defragmentation using OPTIMIZEMariadb 表碎片整理使用 OPTIMIZE
【发布时间】：2018-07-12 04:55:01
【问题描述】：

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

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

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

这是一个错误还是我在这里遗漏了什么，请告知。

【问题讨论】：

你可能应该写一个错误报告。同时，OPTIMIZE TABLE 和它所做的碎片整理几乎不需要。为什么要使用它？
感谢您的评论，我试图获得最佳选择来设置数据库维护以使用 Online DDL 方法清除碎片表，我遇到了这个新添加并想衡量哪个适合更好的是，还有一个主要目的是对一些在线表进行索引重建。
我对@987654323@ 的看法：永远不要对 InnoDB 表这样做。
@rick-james 为什么不呢？

【解决方案1】：

速度的好处几乎为零。

“点查询”（您有键并且可以直接进入行）取决于 BTree 的深度。对于一百万行，深度约为 3。对于 trillion 行，约为 6。优化表不太可能缩小深度。
“范围扫描”（BETWEEN、> 等）穿过一个块，查看每一行。然后它（通过链接）跳到下一个块，直到找到所有需要的行。当然，您会在未优化的表中触及更多块，但大部分工作是访问每一行。

空间的好处是有限的。

INSERT 可以添加到非完整块中，也可以将完整块拆分为两个半完整块。稍后，两个相邻的、有点空的块将被合并在一起。因此，BTree 自然会倾向于 average 块已满 69% 的状态。也就是OPTIMIZE TABLE对于空间的好处是有限的。
换个说法，OPTIMIZE 可能会将表的磁盘占用空间缩小到原来的 69%，但后续操作只会再次增大表。
如果您使用innodb_file_per_table=OFF，则OPTIMIZE 无法将空闲块返回给操作系统。这样的块可以在将来重复使用INSERTs。

OPTIMIZE TABLE 是侵入性。

大删除

历史和内部原理

老版本做了OPTIMIZE，直截了当：创建一个新表（相同的模式）；将行复制到其中：重命名表；降低。不允许写入。
ALGORITHM=INPLACE 可能锁定几个块，将它们组合起来填满一个块，然后向前滑动。这需要某种程度的锁定。根据问题，听起来它只是锁定了整个表。
请注意，每个 BTree（PK+Data 或二级索引）可以独立“优化”。但是没有命令允许仅对主 BTree（PK+数据）执行此操作。可以通过DROP INDEX + ADD INDEX 来优化单个二级索引，但这会丢失索引。相反，考虑做一个NOCOPYADD INDEX，然后INSTANTDROP INDEX。注意：如果您正在使用 USE_INDEX 或 FORCE INDEX，这可能会受到影响。

（警告：此答案适用于 InnoDB，不适用于 MyISAM。）

【讨论】：