MySQL实战45讲学习笔记：第十三讲

1、引子

常常会有同窗来问我，个人数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小仍是没变？

那么今天，我就和你聊聊数据库表的空间回收，看看如何解决这个问题。

这里，咱们仍是针对 MySQL 中应用最普遍的 InnoDB 引擎展开讨论。一个 InnoDB 表包含两部分，即：表结构定义和数据。在 MySQL 8.0 版本之前，表结构是存在以.frm 为后
缀的文件里。而 MySQL 8.0 版本，则已经容许把表结构定义放在系统数据表中了。由于表结构定义占用的空间很小，因此咱们今天主要讨论的是表数据。

接下来，我会先和你说明为何简单地删除表数据达不到表空间回收的效果，而后再和你介绍正确回收空间的方法。

2、参数 innodb_file_per_table

表数据既能够存在共享表空间里，也能够是单独的文件。这个行为是由参数innodb_file_per_table 控制的：

1. 这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在一块儿；

2. 这个参数设置为 ON 表示的是，每一个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。

从 MySQL 5.6.6 版本开始，它的默认值就是 ON 了。

我建议你不论使用 MySQL 的哪一个版本，都将这个值设置为 ON。由于，一个表单独存储为一个文件更容易管理，并且在你不须要这个表的时候，经过 drop table 命令，系统就会
直接删除这个文件。而若是是放在共享表空间中，即便表删掉了，空间也是不会回收的。

因此，将 innodb_file_per_table 设置为 ON，是推荐作法，咱们接下来的讨论都是基于这个设置展开的。

咱们在删除整个表的时候，可使用 drop table 命令回收表空间。可是，咱们遇到的更多的删除数据的场景是删除某些行，这时就遇到了咱们文章开头的问题：表中的数据被删除
了，可是表空间却没有被回收。

咱们要完全搞明白这个问题的话，就要从数据删除流程提及了。

3、数据删除流程

咱们先再来看一下 InnoDB 中一个索引的示意图。在前面第 4和第 5篇文章中，我和你介绍索引时曾经提到过，InnoDB 里的数据都是用 B+ 树的结构组织的。

图 1 B+ 树索引示意图

假设，咱们要删掉 R4 这个记录，InnoDB 引擎只会把 R4 这个记录标记为删除。若是以后要再插入一个 ID 在 300 和 600 之间的记录时，可能会复用这个位置。可是，磁盘文件的
大小并不会缩小。

如今，你已经知道了 InnoDB 的数据是按页存储的，那么若是咱们删掉了一个数据页上的全部记录，会怎么样？

答案是，整个数据页就能够被复用了。

可是，数据页的复用跟记录的复用是不一样的。

记录的复用，只限于符合范围条件的数据。好比上面的这个例子，R4 这条记录被删除后，若是插入一个 ID 是 400 的行，能够直接复用这个空间。但若是插入的是一个 ID 是 800
的行，就不能复用这个位置了。

而当整个页从 B+ 树里面摘掉之后，能够复用到任何位置。以图 1 为例，若是将数据页page A 上的全部记录删除之后，page A 会被标记为可复用。这时候若是要插入一条
ID=50 的记录须要使用新页的时候，page A 是能够被复用的。

若是相邻的两个数据页利用率都很小，系统就会把这两个页上的数据合到其中一个页上，另一个数据页就被标记为可复用。

进一步地，若是咱们用 delete 命令把整个表的数据删除呢？结果就是，全部的数据页都会被标记为可复用。可是磁盘上，文件不会变小。

你如今知道了，delete 命令其实只是把记录的位置，或者数据页标记为了“可复用”，但磁盘文件的大小是不会变的。也就是说，经过 delete 命令是不能回收表空间的。这些可
以复用，而没有被使用的空间，看起来就像是“空洞”。

实际上，不止是删除数据会形成空洞，插入数据也会。

若是数据是按照索引递增顺序插入的，那么索引是紧凑的。但若是数据是随机插入的，就可能形成索引的数据页分裂。

假设图 1 中 page A 已经满了，这时我要再插入一行数据，会怎样呢？

图 2 插入数据致使页分裂

能够看到，因为 page A 满了，再插入一个 ID 是 550 的数据时，就不得再也不申请一个新的页面 page B 来保存数据了。页分裂完成后，page A 的末尾就留下了空洞（注意：实
际上，可能不止 1 个记录的位置是空洞）。

另外，更新索引上的值，能够理解为删除一个旧的值，再插入一个新值。不难理解，这也是会形成空洞的。

也就是说，通过大量增删改的表，都是多是存在空洞的。因此，若是可以把这些空洞去掉，就能达到收缩表空间的目的。

而重建表，就能够达到这样的目的。

4、重建表

试想一下，若是你如今有一个表 A，须要作空间收缩，为了把表中存在的空洞去掉，你能够怎么作呢？

你能够新建一个与表 A 结构相同的表 B，而后按照主键 ID 递增的顺序，把数据一行一行因为表 B 是新建的表，因此表 A 主键索引上的空洞，在表 B 中就都不存在了。显然地，

表 B 的主键索引更紧凑，数据页的利用率也更高。若是咱们把表 B 做为临时表，数据从表A 导入表 B 的操做完成后，用表 B 替换 A，从效果上看，就起到了收缩表 A 空间的做用。

这里，你可使用 alter table A engine=InnoDB 命令来重建表。在 MySQL 5.5 版本以前，这个命令的执行流程跟咱们前面描述的差很少，区别只是这个临时表 B 不须要你本身
建立，MySQL 会自动完成转存数据、交换表名、删除旧表的操做。

图 3 改锁表 DDL

显然，花时间最多的步骤是往临时表插入数据的过程，若是在这个过程当中，有新的数据要写入到表 A 的话，就会形成数据丢失。所以，在整个 DDL 过程当中，表 A 中不能有更新。
也就是说，这个 DDL 不是 Online 的。

而在MySQL 5.6 版本开始引入的 Online DDL，对这个操做流程作了优化。

我给你简单描述一下引入了 Online DDL 以后，重建表的流程：

1. 创建一个临时文件，扫描表 A 主键的全部数据页；
2. 用数据页中表 A 的记录生成 B+ 树，存储到临时文件中；
3. 生成临时文件的过程当中，将全部对 A 的操做记录在一个日志文件（row log）中，对应的是图中 state2 的状态；
4. 临时文件生成后，将日志文件中的操做应用到临时文件，获得一个逻辑数据上与表 A 相同的数据文件，对应的就是图中 state3 的状态；
5. 用临时文件替换表 A 的数据文件。

图 4 Online DDL

能够看到，与图 3 过程的不一样之处在于，因为日志文件记录和重放操做这个功能的存在，这个方案在重建表的过程当中，容许对表 A 作增删改操做。这也就是 Online DDL 名字的来源。

我记得有同窗在第 6 篇讲表锁的文章《全局锁和表锁 ：给表加个字段怎么索这么多阻碍？》的评论区留言说，DDL 以前是要拿 MDL 写锁的，这样还能叫 Online DDL 吗？
确实，图 4 的流程中，alter 语句在启动的时候须要获取 MDL 写锁，可是这个写锁在真正拷贝数据以前就退化成读锁了。

为何要退化呢？为了实现 Online，MDL 读锁不会阻塞增删改操做。

那为何不干脆直接解锁呢？为了保护本身，禁止其余线程对这个表同时作 DDL。

而对于一个大表来讲，Online DDL 最耗时的过程就是拷贝数据到临时表的过程，这个步骤的执行期间能够接受增删改操做。因此，相对于整个 DDL 过程来讲，锁的时间很是
短。对业务来讲，就能够认为是 Online 的。

须要补充说明的是，上述的这些重建方法都会扫描原表数据和构建临时文件。对于很大的表来讲，这个操做是很消耗 IO 和 CPU 资源的。所以，若是是线上服务，你要很当心地控
制操做时间。若是想要比较安全的操做的话，我推荐你使用 GitHub 开源的 gh-ost 来作。

5、Online 和 inplace

说到 Online，我还要再和你澄清一下它和另外一个跟 DDL 有关的、容易混淆的概念inplace 的区别。

你可能注意到了，在图 3 中，咱们把表 A 中的数据导出来的存放位置叫做 tmp_table。这是一个临时表，是在 server 层建立的。

在图 4 中，根据表 A 重建出来的数据是放在“tmp_file”里的，这个临时文件是 InnoDB在内部建立出来的。整个 DDL 过程都在 InnoDB 内部完成。对于 server 层来讲，没有把
数据挪动到临时表，是一个“原地”操做，这就是“inplace”名称的来源。

因此，我如今问你，若是你有一个 1TB 的表，如今磁盘间是 1.2TB，能不能作一个inplace 的 DDL 呢？

答案是不能。由于，tmp_file 也是要占用临时空间的。

咱们重建表的这个语句 alter table t engine=InnoDB，其实隐含的意思是：

alter table t engine=innodb,ALGORITHM=inplace;

跟 inplace 对应的就是拷贝表的方式了，用法是：

alter table t engine=innodb,ALGORITHM=copy;

当你使用 ALGORITHM=copy 的时候，表示的是强制拷贝表，对应的流程就是图 3 的操做过程。

但我这样说你可能会以为，inplace 跟 Online 是否是就是一个意思？

其实不是的，只是在重建表这个逻辑中恰好是这样而已。

好比，若是我要给 InnoDB 表的一个字段加全文索引，写法是：

alter table t add FULLTEXT(field_name);

这个过程是 inplace 的，但会阻塞增删改操做，是非 Online 的。

若是说这两个逻辑之间的关系是什么的话，能够归纳为：

1. DDL 过程若是是 Online 的，就必定是 inplace 的；
2. 反过来未必，也就是说 inplace 的 DDL，有可能不是 Online 的。截止到 MySQL8.0，添加全文索引（FULLTEXT index）和空间索引 (SPATIAL index) 就属于这种状况。

最后，咱们再延伸一下。

在第 10 篇文章《MySQL 为何有时候会选错索引》的评论区中，有同窗问到使用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。

6、小结

今天这篇文章，我和你讨论了数据库中收缩表空间的方法。

如今你已经知道了，若是要收缩一个表，只是 delete 掉表里面不用的数据的话，表文件的大小是不会变的，你还要经过 alter table 命令重建表，才能达到表文件变小的目的。我
跟你介绍了重建表的两种实现方式，Online DDL 的方式是能够考虑在业务低峰期使用的，而 MySQL 5.5 及以前的版本，这个命令是会阻塞 DML 的，这个你须要特别当心。
最后，又到了咱们的课后问题时间。

假设如今有人碰到了一个“想要收缩表空间，结果拔苗助长”的状况，看上去是这样的：

1. 一个表 t 文件大小为 1TB；
2. 对这个表执行 alter table t engine=InnoDB；
3. 发现执行完成后，空间不只没变小，还稍微大了一点儿，好比变成了 1.01TB。

你以为多是什么缘由呢 ？

你能够把你以为可能的缘由写在留言区里，我会在下一篇文章的末尾把你们描述的合理的缘由都列出来，之后其余同窗就不用掉到这样的坑里了。感谢你的收听，也欢迎你把这篇
文章分享给更多的朋友一块儿阅读。

7、上期问题时间

在上期文章最后，我留给你的问题是，若是一个高配的机器，redo log 设置过小，会发生什么状况。

每次事务提交都要写 redo log，若是设置过小，很快就会被写满，也就是下面这个图的状态，这个“环”将很快被写满，write pos 一直追着 CP。

这时候系统不得不中止全部更新，去推动 checkpoint。

这时，你看到的现象就是磁盘压力很小，可是数据库出现间歇性的性能下跌。

8、经典留言

一、undifined

老师，有几个问题：

1.Truncate 会释放表空间吗
2.重建表的时候若是没有数据更新，有没有可能产生页分裂和空洞
3.页分裂是发生在索引仍是数据上
4.应用 row log 的过程会不会再次产生页分裂和空洞
5.不影响增删改，就是 Online；相对 Server层没有新建临时表，就是 inplace，这里怎么判断是否是相对 Server 层没有新建临时表
辛苦老师解答一下，谢谢老师

做者回复:

1. Truncate 能够理解为drop+create
2. Online 能够认为没有
3. 数据也是索引哦
4. 可能会
5. 好问题，我放到明天答疑部分

二、godtrue

1：为啥删除了表的一半数8据，表文文件大小没变化？

由于delete 命令其实只是把记录的位置，或者数据页标记为了“可复用”，但磁盘文件的大小是不会变的。也能够认为是一种逻辑删除，因此物理空间没有实际释放，
只是标记为可复用，表文件的大小固然是不变的啦！

2：表的数据信息存在哪里？

表数据信息可能较小也可能巨大无比，她能够存储在共享表空间里，也能够单独存储在一个以.ibd为后缀的文件里，由参数innodb_file_per_table来控制，
老师建议老是做为一个单独的文件来存储，这样很是容易管理，而且在不须要的时候，使用drop table命令也能直接把对应的文件删除，
若是存储在共享空间之中即便表删除了空间也不会释放。

3：表的结构信息存在哪里？

首先，表结构定义占有的存储空间比较小，在MySQL8.0以前，表结构的定义信息存在以.frm为后缀的文件里，在MySQL8.0以后，
则容许把表结构的定义信息存在系统数据表之中。

系统数据表，主要用于存储MySQL的系统数据，好比：数据字典、undo log(默认)等文件

4：如何才能删除表数据后，表文件大小就变小？

重建表，消除表由于进行大量的增删改操做而产生的空洞，使用以下命令：

1：alter table t engine=InnoDB
2：optimize table t( 等于 recreate+analyze)。
3：truntace table t (等于drop+create)
5：空洞是啥？咋产生的？

五、空洞就是那些被标记可复用可是还没被使用的存储空间。

1. 使用delete命令删除数据会产生空洞，标记为可复用
2. 插入新的数据可能引发页分裂，也可能产生空洞
3. 修改操做，有时是一种先删后插的动做也可能产生空洞