作者:杨奇龙
网名“北在南方”,资深 DBA,主要负责数据库架构设计和运维平台开发工作,擅长数据库性能调优、故障诊断。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
一 前言
某个客户反馈查询数据库发现 information_schema.tables 的 data_free 值突发异常,达到 13G 左右。如图:

需要排查什么原因导致的,本文梳理排查的过程和和解决问题的方法。
二 排查
2.1 分析
首先 data_free 的含义是 表空间 ibd 文件经过写入和删除之后,留下的没有回收的碎片空间大小。
让现场的同学同时检查主备库,对比有没有文件大小和配置上的差异。 发现主库的data_free 值是 13G 左右, 备库正常。

看结果猜测和主库上的某些请求动作有关,空洞是 MySQL 因为 sql 写入而请求分配的空间没有自动回收的结果。基于前线给的信息,没有其他思路,再看前线发的截图:

意外从 截图的 ib

本文通过一个客户案例探讨了MySQL数据库中information_schema.tables的data_free值异常升高的问题,发现与ibtmp1临时表空间有关。在执行特定SQL操作时,ibtmp1文件未被正确回收,导致空间占用过大。解决方案包括调整innodb_temp_data_file_path参数限制其最大值,或者通过重启数据库来回收空间。此外,文章还介绍了临时表的使用场景、相关参数和元数据。
最低0.47元/天 解锁文章
1374

被折叠的 条评论
为什么被折叠?



