Mysql 使用OPTIMIZE进行Mariadb表碎片整理

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

我已经用Alogorithm=INPLACE测试了Alter Table，效果很好，但我正在尝试使用innodb_碎片整理和使用optimize，以避免像Alter Table INPLACE算法那样在重建表时创建临时文件

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

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

速度的好处几乎为零。

• “点查询”（在这里您有键，可以直接转到行）取决于BTree的深度。对于一百万行，深度大约为3。对于一万亿行，大约6行。优化表格不太可能缩小深度

• “范围扫描”（介于、
  等之间的

  ）穿过一个块，查看每一行。然后它（通过链接）跳到下一个块，直到找到所需的所有行。当然，在一个未优化的表中会涉及更多的块，但大部分工作都是访问每一行
  

空间效益有限。

• INSERT

  可以添加到非完整块，也可以将完整块拆分为两个半完整块。稍后，两个相邻的、有点空的块将合并在一起。因此，BTree自然会被吸引到平均块已满69%的状态。也就是说，

  为空间优化表

  的好处是有限的

• 换言之，

  OPTIMIZE

  可能会将表的磁盘占用空间缩小到原来的69%，但后续操作只会使表再次增长

• 如果使用的是

  innodb\u file\u per\u table=OFF

  ，则

  OPTIMIZE

  无法将空闲块返回到操作系统。这样的块可以在将来的

  插入中重用
  

优化表

具有侵入性。

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

• 如果您使用的是复制，后续写入可能会堆积在

  优化

  之后，从而使从机无法到达第二个

大删除

• 删除大量行后，优化

  可能会有好处，但请检查69%的估计值
  

• 如果大的删除是一种常见的情况，那么可能还有其他的事情需要你去做。看

历史和内部结构

• 旧版本以一种简单的方式进行了优化：创建一个新表（相同的模式）；将行复制到其中：重命名表；滴不允许写入

• ALGORITHM=INPLACE

  可能会锁定几个块，将它们组合起来填充一个块，然后向前滑动。这需要一定程度的锁定。基于这个问题，它听起来像是简单地锁定了整个表
• 请注意，每个BTree（PK+数据或二级索引）都可以独立地“优化”。但是没有命令允许只对主BTree（PK+数据）执行此操作。通过

  删除索引

  +

  添加索引

  ，可以优化单个辅助索引，但这样会丢失索引。相反，请考虑做<代码> NoCope<代码> >代码>添加索引< /代码>，然后<代码>即时< /代码>代码>下拉索引< /代码>。警告：如果您正在使用，这可能会影响

  使用索引

  或

  强制索引

---

（注意：这个答案适用于InnoDB，而不是MyISAM。）

您可能应该编写一份错误报告。同时，

optimizetable

和它所做的碎片整理几乎是不需要的。你为什么要使用它？谢谢你的评论，我正在尝试使用在线DDL方法获取设置数据库维护以清除碎片表的最佳选项，我遇到了这个新的添加项，想确定哪个更适合，还有一个主要目的是在线对一些表进行索引重建。我对

优化表
的看法是：永远不要对InnoDB表进行索引重建。@rick james为什么不呢？