1. 个人技术分享首页

MySQL删除数据,表文件大小依然没变的原因

对于运行很长时间的数据库来说,往往会出现表占用存储空间过大的问题,可是将许多没用的表删除之后,表文件的大小并没有改变,想解决这个问题,就需要了解 InnoDB 如何回收表空间的。

对于一张表来说,占用空间重要分为两部分,表结构和表数据。通常来说,表结构定义占用的空间很小。所以空间的问题主要和表数据有关。

在 MySQL 8.0 前,表结构存储在以 .frm 为后缀的文件里。在 8.0,允许将表结构定义在系统数据表中。

关于表数据的存放

可以将表数据存在共享表空间,或者单独的文件中,通过 innodb_file_per_table 来控制。

  • 如果为 OFF ,表示存在系统共享表空间中,和数据字典一起
  • 如果为 ON,每个 InnoDB 表结构存储在 .idb 为后缀的文件中

在 5.6.6 以后,默认值为 ON.

建议将该参数设置为 ON,这样在不需要时,通过 drop table 命令,系统就会直接删除该文件。

但在共享表空间中,即使表删掉,空间也不会回收。

truncate = drop + create 

数据删除流程

但有时使用 delete删除数据时,仅仅删除的是某些行,但这可能就会出现表空间没有被回收的情况。

我们知道,MySQL InnoDB 中采用了 B+ 树作为存储数据的结构,也就是常说的索引组织表,并且数据时按照页来存储的。

在删除数据时,会有两种情况:

  • 删除数据页中的某些记录
  • 删除整个数据页的内容

比如想要删除 R4 这条记录:

MySQL删除数据,表文件大小依然没变的原因

InnoDB 直接将 R4 这条记录标记为删除,称为可复用的位置。如果之后要插入 ID 在 300 到 700 间的记录时,就会复用该位置。由此可见,磁盘文件的大小并不会减少。

而且记录的复用,只限于符合范围条件的数据。之后要插入 ID 为 800 的记录,R4 的位置就不能被复用了。

再比如要是删除了整个数据页的内容,假设删除 R3 R4 R5,为 Page A 数据页。

这时 InnoDB 就会将整个 Page A 标记为删除状态,之后整个数据都可以被复用,没有范围的限制。比如要插入 ID=50 的内容就可以直接复用。

并且如果两个相邻的数据页利用率都很小,就会把两个页中的数据合到其中一个页上,另一个页标记为可复用。

综上,无论是数据行的删除还是数据页的删除,都是将其标记为删除的状态,用于复用,所以文件并不会减小。对应到具体的操作就是使用 delete 命令.

而且,我们还可以发现,对于第一种删除记录的情况,由于复用时会有范围的限制,所以就会出现很多空隙的情况,比如删除 R4,插入的却是 ID=800.

插入操作也会造成空隙

在插入数据时,如果数据按照索引递增顺序插入,索引的结构会是紧凑的。但如果是随机插入的,很可能造成索引数据页分裂。

比如给已满的 Page A 插入数据。

MySQL删除数据,表文件大小依然没变的原因

由于 Page A 满了,所以要申请 Page B,调整 Page A 的过程到 Page B,这也称为页分裂。

结束后 Page A 就有了空隙。

另外对于更新操作也是,先删除再插入,也会造成空隙。

进而对于大量进行增删改的表,都有可能存在空洞。如果把空洞去掉,自然空间就被释放了。

使用重建表

为了把表中的空隙去掉,这时就可以采用重新建一个与表 A 结构相同的表 B,然后按照主键 ID 递增的顺序,把数据依次插入到 B 表中。

由于是顺序插入,自然 B 表的空隙不存在,数据页的利用率也更高。之后用表 B 代替表 A,好像起到了收缩表 A 空间的作用。

具体通过:

alter table A engine=InnoDB

在 5.5 版本后,该命令和上面提到的流程差不多,而且 MySQL 会自己完成数据,交换表名,删除旧表的操作。

MySQL删除数据,表文件大小依然没变的原因

但这就有一个问题,在 DDL 中,表 A 不能有更新,此时有数据写入表 A 的话,就会造成数据丢失。

在 5.6 版本后引入了 Online DDL。

Online DDL

Online DDL 在其基础上做了如下的更新:

MySQL删除数据,表文件大小依然没变的原因

重建表的过程如下:

  1. 建立一个临时文件,扫描表 A 主键的所有数据页。
  2. 用生成的数据页生成 B+ 树,存储到临时文件中。
  3. 生成临时文件时,如果有对 A 的操作,将其记录在日志文件中,对应图中 state 2 的状态。
  4. 临时文件生成后,将日志文件应用到临时文件中,得到与 A 表相同的数据文件,对应 state 3 状态。
  5. 用临时文件替换 A 表的数据文件。

由于 row log 日志文件存在,可以在重建表示,对表 A 进行 DML 操作。

需要注意的是,在 alter 语句执行前,会先申请 MDL 写锁,但在拷贝数据前会退化成 MDL 读锁,从而支持 DML 操作。

至于为什么不大 MDL 去掉,是防止其他线程对这个表同时做 DDL 操作。

对于大表来说,该操作很耗 IO 和 CPU 资源,所以在线上操作时,要控制操作时间。如果为了保证安全,推荐使用 gh-ost 来迁移。

Online 和 inplace

首先说一下 inplace 和 copy 的区别:

在 Online DDL 中,表 A 重建后的数据放在 tmp_file 中,这个临时文件是在 InnoDB 内部创建出来的。整个 DDL 在 InnoDB 内部完成。进而对于 Server 层来说,并没有数据移动到临时表中,是一个 “原地” 操作,所以叫 “inplace” .

而在之前普通的 DDL 中,创建后的表 A 是在 tmp_table 是 Server 创建的,所以叫 “copy”

对应到语句其实就是:

需要注意的是 inplace 和 Online 并不是对应关系:

  1. DDL 过程是 Online,则一定是 inplace
  2. 如果是 inplace 的 DDL 不应当是 Online,如在

拓展

说一下 optimize,analyze,alter table 三种重建表之间的区别:

  1. alter table t engine = InnoDB(也就是 recreate)默认的是 Oline DDL 过程。
  2. analyze table t 不是重建表,仅仅是对表的索引信息做重新统计,没有修改数据,期间加 MDL 读锁。
  3. optimize table t 等于上两步的操作。

在事务里面使用 alter table 默认会自动提交事务,保持事务一致性

如果有时,在重建某张表后,空间不仅没有变小,甚至还变大了一点点。这时因为,重建的这张表本身没有空隙,在 DDL 期间,刚好有一些 DML 执行,引入了一些新的空隙。

而且 InnoDB 不会把整张表填满,每个页留下 1/16 给后续的更新用,所以可能远离是紧凑的,但重建后变成的稍有空隙。

总结

现在我们知道,在使用 delete 删除数据时,其实对应的数据行并不是真正的删除,InnoDB 仅仅是将其标记成可复用的状态,所以表空间不会变小。

通常来说,在标记复用空间时分为两种,一种是仅将某些数据页中的位置标记为删除状态,但这样的位置只会在一定范围内使用,会出现空隙的情况。

另一种是将整个数据页标记成可复用的状态,这样的数据页没有限制,可直接复用。

为了解决这个问题,我们可以采用重建表的方式,其中在 5.6 版本后,创建表已经支持 Online 的操作,但最后是在业务低峰时使用

文章来源于互联网:MySQL删除数据,表文件大小依然没变的原因

原创文章,作者:admin,如若转载,请注明出处:https://www.aliyunsolution.com/3287.html