ENGINE=InnoDB 来重建这些表，但是这样会导致表的拷贝，如果临时空间不足甚至不足以进行一次 OPTIMIZE TABLE 操作。并且如果你用的是共享表空间方式，OPTIMIZE TABLE 会导致你的共享表空间文件持续增大，因为整理的索引和数据都追加在数据文件的末尾。

这样配置以后新的碎片整理功能就会替代原有的 OPTIMIZE TABLE 算法，不会有新的表生成，也不需要把旧表的数据拷贝到新表。新的算法会载入 n 个页面尝试把上面的记录紧凑的合并到一起，从而让页面存满记录，然后释放掉完全空了的页面。

  • innodb_defragment: 打开或关闭InnoDB碎片整理算法。当设置为FALSE时，所有正在做的整理操作会暂停。暂停的整理操作会在变量设置为TRUE时重新开始。默认值是FALSE。
  • innodb_defragment_n_pages: 一次性读取多少个页面进行合并整理操作。取值范围是2~32，默认值是7。
  • innodb_defragment_stats_accuracy: 统计信息写到持久化存储前可以有多少个整理统计信息的变更。设置为0表示不禁用整理统计追踪，默认值是0.
  • innodb_defragment_fill_factor: 可以设置为[0.7~1]之间的值，让整理算法知道应该把一个页面填的多满。默认值是0.9. 设置为0.7以下没有什么意义。这个变量和 innodb_defragment_fill_factor_n_recs 一起可以让页面不至于被塞得太满，从而减少后面插入记录导致的页面分裂。上面这量个变量也是告诉我们，持续的整理操作可以让InnoDB更高效。
  • innodb_defragment_frequency: 对单个索引每秒的整理操作不要超过这个数量。这个变量控制了整理线程在一段时间内请求索引的 X_LOCK 的次数。整理线程会检查是当前操作的索引离上次操作的时间否超过了1/defragment_frequency (s) ，如果还没过足够长的时间，则把索引重新放回队列中。实际的操作频率只会比这个值低。
  • Innodb_defragment_compression_failures: 整理碎片时重新压缩页面失败的次数。
  • Innodb_defragment_count: 整理操作的次数。

现在如果我们删掉 3/4 的记录就会在页面中留下很多空洞，然后我们通过 OTPTIMIZE TABLE 执行整理操作：