共计 1436 个字符，预计需要花费 4 分钟才能阅读完成。
I、参数 innodb_file_per_table
| OFF | 表的数据放在零碎共享表空间，也就是跟数据字典放在一起 |
| ON | 每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中，V5.6.6- 默认 |
1、倡议 ON，因为，一个表独自存储为一个文件更容易治理，而且 drop table 命令间接删除这个文件。而如果是放在共享表空间中，即便表删掉了，空间也是不会回收的。2、删除整个表时应用 drop table 命令回收表空间。然而删除某些行就会遇到问题：表中的数据被删除了，然而表空间却没有被回收。II、为什么表中的数据被删除了，然而表空间却没有被回收
1、删除一行只是标记为删除，理论磁盘空间未回收，可复用。
2、delete 命令把整个表的数据删除的后果是，所有的数据页都会被标记为可复用。然而磁盘上，文件不会变小。
这些能够复用，而没有被应用的空间，看起来就像是“空洞”。3、空洞的起因：
①删除表记录，被删除的记录只是被标记删除，索引值所在的空间能被复用，然而没有真正的删除；②新增表记录，如果索引的值是随机扩散的，那么会造成数据页的决裂，也会造成空洞；
③更新索引上的值，实际上是把旧值标记为删除，而后新增一个新值，旧值尽管能被复用，然而还是造成了空洞。
III、重建表 alter table A engine=InnoDB 以去除空洞，膨胀空间
MySQL 5.6 之前要求在整个 DDL 过程中，表 A 中不能有更新。也就是说，这个 DDL 不是 Online 的。如果在这个过程中，有新的数据要写入到表 A 的话，就会造成数据失落。
Online DDL（V5.6-）1、建设一个临时文件，扫描表 A 主键的所有数据页；
2、用数据页中表 A 的记录生成 B+ 树，存储到临时文件中；
3、生成临时文件的过程中，将所有对 A 的操作记录在一个日志文件（row log）中，对应的是图中 state2 的状态；
4、临时文件生成后，将日志文件中的操作利用到临时文件，失去一个逻辑数据上与表 A 雷同的数据文件，对应的就是图中 state3 的状态；
5、用临时文件替换表 A 的数据文件。
Online DDL 其实是会先获取 MDL 写锁, 再进化成 MDL 读锁；但 MDL 写锁持有工夫比拟短，所以能够称为 Online；而 MDL 读锁，不阻止数据增删查改，但会阻止其它线程批改表构造；IV、Online 和 inplace
1、DDL 过程如果是 Online 的，就肯定是 inplace 的；
2、反过来未必，也就是说 inplace 的 DDL，有可能不是 Online 的。截止到 MySQL 8.0，添
加全文索引（FULLTEXT index）和空间索引 (SPATIAL index) 就属于这种状况。
V、optimize table、analyze table 和 alter table
1、从 MySQL 5.6 版本开始，alter table t engine = InnoDB（也就是 recreate）默认的就是下面图 4 的流程了；
2、analyze table t 其实不是重建表，只是对表的索引信息做从新统计，没有批改数据，这个过程中加了 MDL 读锁；
3、optimize table t 等于 recreate+analyze。
VI、留神点：
1、如果要膨胀一个表，只是 delete 掉表外面不必的数据的话，表文件的大小是不会变的，你还要通过 alter table 命令重建表，能力达到表文件变小的目标。
2、重建表的两种实现形式，Online DDL 的形式是能够思考在业务低峰期应用的，而 MySQL 5.5 及之前的版本，这个命令是会阻塞 DML 的，须要特地小心。
