这里针对MySQL中应用最广泛的InnoDB引擎展开讨论,一个 InnoDB 表包含两部分，即：表结构定义和数据。在 MySQL 8.0 版本以前，表结构是存在以.frm 为后缀的文件里。而 MySQL 8.0 版本，则已经允许把表结构定义放在系统数据表中了。因为表结构定义占用的空间很小，所以今天主要讨论的是表数据。
参数 innodb_file_per_table
表数据既可以存在共享表空间里，也可以是单独的文件。这个行为是由参数 innodb_file_per_table 控制的：
1.这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在一起；
2.这个参数设置为 ON 表示的是，每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。
从 MySQL 5.6.6 版本开始，它的默认值就是 ON 了。
建议不论使用哪个版本都将这个值设置为ON.因为,一个表单独存储为一个文件更容易管理,而且在不需要这个表的时候,通过drop table命令,系统就会直接删除这个文件.而如果是放在共享表空间中,即使表删掉了,空间也不会回收.
在删除整个表的时候，可以使用 drop table 命令回收表空间。但是，遇到的更多的删除数据的场景是删除某些行,这时就遇到了文章开头的问题：表中的数据被删除了，但是表空间却没有被回收。
数据删除流程
InnoDB里的数据都是用B+树的结构组织的.
假设存在三条数据id分别为300,500,600,那么删除id=500这条记录,InnoDB引擎指挥吧这个记录标记为删除.如果之后再插入一条记录在300和600之间的记录时,可能会复用这个位置.但是磁盘文件的大小并不会缩小.
之所以会出现上述现象,是因为InnoDB的数据是按页存储的,那么问题来了如果删除一个数据页上的所有记录会怎么样?
结果是整个数据页都可以复用,这里就有点像容器的概念了,磁盘上被占用的空间是被这个容器所占用,你把容器内的数据删除,但是容器还是在那里,所以磁盘文件不会因此而缩小.
但是,数据页的复用和记录的复用是不同的.
记录的复用，只限于符合范围条件的数据。比如上面的这个例子，id=500的这条记录被删除之后,如果插入一个id是400的行,可以直接复用这个空间.但是如果插入的是id=800的行就不能复用这个位置了.
而当整个页从 B+ 树里面摘掉以后，可以复用到任何位置。
如果相邻的两个数据页利用率都很小，系统就会把这两个页上的数据合到其中一个页上，另外一个数据页就被标记为可复用。
也就是说，通过 delete 命令是不能回收表空间的。这些可以复用，而没有被使用的空间，看起来就像是“空洞”。
实际上，不止是删除数据会造成空洞，插入数据也会。
如果数据是按照索引递增顺序插入的，那么索引是紧凑的。但如果数据是随机插入的，就可能造成索引的数据页分裂。
另外,更新索引上的值，可以理解为删除一个旧的值，再插入一个新值。不难理解，这也是会造成空洞的。
也就是说，经过大量增删改的表，都是可能是存在空洞的。所以，如果能够把这些空洞去掉，就能达到收缩表空间的目的。而重建表，就可以达到这样的目的。
重建表
可以使用alter table XX engine=InnoDB 命令来重建表.在Mysql5.5版本之前,这个命令的执行流程就相当于复制一张同样结构的表然后将原表的数据copy过去,这样新表的主键索引就更紧凑了,数据页的利用率也就更高了.
但是如果重建表过程中有新数据写入到旧表,就会造成数据丢失.因此在整个DDL过程中,旧表不能有更新.也就是说这个DDL不是Online的.
而在 MySQL 5.6 版本开始引入的 Online DDL，对这个操作流程做了优化。
简单描述一下引入了 Online DDL 之后，重建表的流程：
1.建立一个临时文件,扫描表A主键的所有数据页;
2.用数据页A的记录生成B+树,存储到临时文件中;
3.生成临时文件的过程中,将所有对A的操作记录在一个日志文件中(row log);
4.临时文件生成后,将日志文件中的操作应用到临时文件,得到一个逻辑数据上与旧表相同的数据文件;
5.用临时文件替换旧表的数据文件;
由于日志文件和重放操作这个功能的存在,这个方案在重建表的过程中,允许对旧表做增删改操作.
需要补充说明的是，上述的这些重建方法都会扫描原表数据和构建临时文件。对于很大的表来说，这个操作是很消耗 IO 和 CPU 资源的。
