今天就跟大家聊聊有关MySQL删除数据表文件大小不变的原因是什么,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
对于运行很长时间的数据库来说,往往会出现表占用存储空间过大的问题,可是将许多没用的表删除之后,表文件的大小并没有改变,想解决这个问题,就需要了解 InnoDB 如何回收表空间的。
对于一张表来说,占用空间重要分为两部分,表结构和表数据。通常来说,表结构定义占用的空间很小。所以空间的问题主要和表数据有关。
在 MySQL 8.0 前,表结构存储在以 .frm 为后缀的文件里。在 8.0,允许将表结构定义在系统数据表中。
关于表数据的存放
可以将表数据存在共享表空间,或者单独的文件中,通过 innodb_file_per_table
来控制。
在 5.6.6 以后,默认值为 ON.
建议将该参数设置为 ON,这样在不需要时,通过 drop table 命令,系统就会直接删除该文件。
但在共享表空间中,即使表删掉,空间也不会回收。
truncate = drop + create
数据删除流程
但有时使用 delete
删除数据时,仅仅删除的是某些行,但这可能就会出现表空间没有被回收的情况。
我们知道,MySQL InnoDB 中采用了 B+ 树作为存储数据的结构,也就是常说的索引组织表,并且数据时按照页来存储的。
在删除数据时,会有两种情况:
比如想要删除 R4 这条记录:
InnoDB 直接将 R4 这条记录标记为删除,称为可复用的位置。如果之后要插入 ID 在 300 到 700 间的记录时,就会复用该位置。由此可见,磁盘文件的大小并不会减少。
而且记录的复用,只限于符合范围条件的数据。之后要插入 ID 为 800 的记录,R4 的位置就不能被复用了。
再比如要是删除了整个数据页的内容,假设删除 R3 R4 R5,为 Page A 数据页。
这时 InnoDB 就会将整个 Page A 标记为删除状态,之后整个数据都可以被复用,没有范围的限制。比如要插入 ID=50 的内容就可以直接复用。
并且如果两个相邻的数据页利用率都很小,就会把两个页中的数据合到其中一个页上,另一个页标记为可复用。
综上,无论是数据行的删除还是数据页的删除,都是将其标记为删除的状态,用于复用,所以文件并不会减小。对应到具体的操作就是使用 delete 命令.
而且,我们还可以发现,对于第一种删除记录的情况,由于复用时会有范围的限制,所以就会出现很多空隙的情况,比如删除 R4,插入的却是 ID=800.
插入操作也会造成空隙
在插入数据时,如果数据按照索引递增顺序插入,索引的结构会是紧凑的。但如果是随机插入的,很可能造成索引数据页分裂。
比如给已满的 Page A 插入数据。
由于 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 会自己完成数据,交换表名,删除旧表的操作。
但这就有一个问题,在 DDL 中,表 A 不能有更新,此时有数据写入表 A 的话,就会造成数据丢失。
在 5.6 版本后引入了 Online DDL。
Online DDL
Online DDL 在其基础上做了如下的更新:
重建表的过程如下:
由于 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"
对应到语句其实就是:
-- alter table t engine=InnoDB 默认为下面 alter table t engine=innodb,ALGORITHM=inplace; -- 走的就是 server 拷贝的过程 alter table t engine=innodb,ALGORITHM=copy;
需要注意的是 inplace 和 Online 并不是对应关系:
拓展
说一下 optimize,analyze,alter table 三种重建表之间的区别:
在事务里面使用 alter table 默认会自动提交事务,保持事务一致性
如果有时,在重建某张表后,空间不仅没有变小,甚至还变大了一点点。这时因为,重建的这张表本身没有空隙,在 DDL 期间,刚好有一些 DML 执行,引入了一些新的空隙。
而且 InnoDB 不会把整张表填满,每个页留下 1/16 给后续的更新用,所以可能远离是紧凑的,但重建后变成的稍有空隙。
总结
现在我们知道,在使用 delete 删除数据时,其实对应的数据行并不是真正的删除,InnoDB 仅仅是将其标记成可复用的状态,所以表空间不会变小。
通常来说,在标记复用空间时分为两种,一种是仅将某些数据页中的位置标记为删除状态,但这样的位置只会在一定范围内使用,会出现空隙的情况。
另一种是将整个数据页标记成可复用的状态,这样的数据页没有限制,可直接复用。
为了解决这个问题,我们可以采用重建表的方式,其中在 5.6 版本后,创建表已经支持 Online 的操作,但最后是在业务低峰时使用
看完上述内容,你们对MySQL删除数据表文件大小不变的原因是什么有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。