MYSQL 5.7 到底 OPTIMIZE Table 塞不塞 DML

问题的起因是另外某篇文字中，对于optimize table 理解不深，说出optimize table 时会和  vacuum full 一样阻塞表的DML操作，马上就有好友指出，你说的不对，并拿出evidence.

所以借此篇，1来证明optimize table 不阻塞DML 2 表示对好友lmongo的感谢， 有一个能指出你错误，并大胆友善说出来的人，不多，要感谢。

先写一段半吊子的python，来作为测试时针对这张表不断地 DML

测试的方式是通过python来尽可能的插入数据，并且在创造另外的3个Python来玩命的update 表中的任意的记录。然后对一个有上千万数据库的表进行optimize , alter table engine = innodb; alter table force；的操作。

这个操作的主要的重点是优化表重新组织表数据和相关索引数据的物理存储，减少存储空间，提高访问表时的I/O效率。

在操作之前我们也要知道， 1 optimize table 仅仅支持  innodb , myisam archive 等类型数据库引起的表。optimize 支持分区表。

这就是我错误的地方，optimize table 是支持在线DDL ，并且加锁只在perpare 和 commit 两个阶段。使用在线DDL优化表不支持包含全文索引的InnoDB表。而是使用表复制方法。

验证开始，执行python 程序，表开始灌入数据，同时也进行3个线程的update操作。 

操作中，从PYTHON 插入和UPDATE 数据库的情况，基本上没有延迟和明显的抖动。

这也是证明了上述整理磁盘碎片的方法，是DDL online。

而我为什么会有这个错误的概念，主要还是对MYSQL 的部分知识停留在MYSQL 5.6 或更早的知识记忆中。所以相关的知识还是要不断更新，和学习，尤其MYSQL 8 具有更多的新技能和技术，更应该去更新知识。避免犯一些低级错误。

另外如果是大表，需要做optimize table 时如果表中包含大量的索引，也可以直接先清理一些，不常用的索引，加速optimize table 的速度。另外也对比了 MYSQL 5.7 和 8.0 的文档，目前暂无特别的改变。

下图证明在操作时会产生新的临时 frm 和 ibd文件

通过gdb跟踪，在操作时会与以下文件有关。InnoDB makes considerable effort to make such locks unnecessary, by using techniques such as online DDL, row locks and consistent reads for processing DML

之所以DDL online 也是因为使用row lock 和一致性读等技术，避免了table lock。