hello，大家好，我是张张，「架构精进之路」公号作者。

1、应用背景

在日常工作开发中，在MySQL中，如果我们对大表频繁进行insert和delete操作，那么时间一长，这个表中会出现很多"空洞"，也就是表碎片。

碎片产生的原因是insert随机值作为主键id，会产生很多数据页分裂操作；而delete掉一些排列有序的主键值，这些被delete的空间不会直接释放，而是仅仅进行delete的标记，这些空间如果不能被利用，那就会变成"空洞"。

2、重建表

关于重建表，这时候新建一张结构一样的临时表，把表内的数据导入到临时表，直接删除旧表，然后将临时表替换为旧表，从而释放这些空余的空间，让数据变得"紧凑些"，完成重建操作。

我们其实可以通过如下命令来重建表：

alter table tableName engine=innodb

在MySQL5.5版本之前，这个命令的执行流程跟1操作差不多，区别只是在于这个临时表不需要你直接创建，MySQL会自动完成转存数据、交换表名、删除旧表的操作。

这个重建表的过程，在MySQL5.5之前，它的执行逻辑是下面这样的：

1、假设原表是A，新建一个表table B，和表A的表结构保持一致；

2、按照主键顺序，将表A的数据一行一行的读出来，插入到表B里面；

3、交换表A和表B的名称。

3、重建实现优化

通过上面的介绍可以发现，花时间最多的步骤是往临时表插入数据的过程，如果在这个过程中，有新的数据要写入到表 A 的话，就会造成数据丢失。

因此，在整个 DDL 过程中，旧表中不能有更新（也就是说，这个 DDL 不是 Online 的）。

在MySQL5.6及以后的版本里面，引入了Online DDL的方法，Online DDL的引入，使得上面的过程有了一点点不同，当执行如下命令的时候，

alter table tableName engine=innodb

MySQL5.6版本开始引入的Online DDL，对这个操作流程做了优化：

1、建立一个临时文件，扫描表A主键的所有数据页；

2、用数据页中表A的记录生产B+树，存储到临时文件中；

3、生产临时文件的过程中，将所有对A的操作记录在一个日志文件（row log）中，对应的是图中state2的状态；

4、临时文件生成后，将日志文件中的操作应用到临时文件，得到一个逻辑数据上与表A相同的数据文件，对应的就是图中state3的状态；

5、用临时文件替换表A的数据文件。

执行alter语句时，需要获取MDL写锁，但是这个写锁在真正拷贝数据之前就退化成读锁。为了实现Online，MDL读锁不会阻塞增删改操作。

那为什么要从写锁退化成读锁而不干脆直接解除锁呢？为了保护自己，禁止其他线程对这个表同时做DDL。

4、答疑解惑

关于重建表，相信大家还会有其他的疑惑，一起来总结下。

Q1、在MySQL5.5之前，我们使用临时表作为重建的中间介质，在MySQL5.6之后，我们使用临时文件作为重建的中间介质，临时表和临时文件的区别是？

A：临时表是创建在server层面的，临时文件是创建在innodb层面的，所以Online DDL的整个过程都是在Innodb内部完成的，这种方法也称之为"inplace"，相对应的，需要借助server层面临时表的过程，称之为"Copy"。

Q2、假设我们有一个1TB的表，磁盘只有1.2TB，那么还可以做inplace的DDL呢？

A：不可以，因为inplace方案中的临时文件也要占用一定的空间。

Q3、inplace 方案进行的表重建操作，都是Online DDL么？

A：不一定，例如增加全文索引的操作，这个操作是inplace的，但是会阻塞增删改查操作，因此不是Online DDL。应该说：Online DDL一定是inplace的，但是inplace方案进行的操作，不一定是Online的。

Q4、某个表的大小是1TB，进行alter table A engine=Innodb之后，表的空间没有缩小，反而增大了一点，这是为什么？

A：可能是因为表之前刚刚进行过一次alter table的操作，而且表上面的并发增删改比较多，在进行alter table 的过程中，这些操作都写进了log中，从而导致表的实际大小会增加。

希望今天的讲解对大家有所帮助，谢谢！

Thanks for reading!

作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。
关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。