1

我们正在运行 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 算法完成的。

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

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

4

1 回答 1

2

速度带来的好处几乎为零。

  • “点查询”(您拥有密钥并且可以直接进入该行)取决于 BTree 的深度。对于一百万行,深度约为 3。对于一万亿行,约为 6。优化表不太可能缩小深度。

  • “范围扫描”(BETWEEN,>等)穿过一个块,查看每一行。然后它(通过链接)跳到下一个块,直到找到所有需要的行。当然,您将在未优化的表中触及更多块,但大部分工作是访问每一行。

空间的好处是有限的。

  • 一个INSERT可以添加到一个非完整的块,或者它可以将一个完整的块分成两个半完整的块。稍后,两个相邻的、有点空的块将被合并在一起。因此,BTree 自然会倾向于平均块为 69% 的状态。也就是说,OPTIMIZE TABLEfor空间的好处是有限的。

  • 换一种说法,OPTIMIZE可能会将表的磁盘占用空间缩小到原来的 69%,但后续操作只会再次增大表。

  • 如果您正在使用innodb_file_per_table=OFF,则OPTIMIZE无法将空闲块返回给操作系统。这样的块可以在未来重复使用INSERTs

OPTIMIZE TABLE侵入性的。

  • 它复制表格,在此过程中将其锁定。这对于需要 100% 正常运行时间的站点来说是不可接受的。

  • 如果您使用复制,后续写入可能会堆积在OPTIMIZE.

大删除

历史和内部

  • 旧版本OPTIMIZE以简单的方式完成:创建一个新表(相同的架构);将行复制到其中:重命名表;降低。不允许写入。
  • ALGORITHM=INPLACE 可能会锁定几个块,将它们组合起来填满一个块,然后向前滑动。这需要某种程度的锁定。根据问题,听起来它只是锁定了整个表。
  • 请注意,每个 BTree(PK+Data 或二级索引)可以独立“优化”。但是没有命令允许仅对主 BTree(PK+数据)执行此操作。可以通过+优化单个二级索引,但这会丢失索引。相反,考虑做一个,然后。注意:这可能会影响或如果您正在使用此类。DROP INDEXADD INDEXNOCOPY ADD INDEX INSTANT DROP INDEXUSE_INDEXFORCE INDEX

(警告:这个答案适用于 InnoDB,而不是 MyISAM。)

于 2019-11-23T20:51:44.860 回答