故障分析 | 从 data_free 异常说起

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

作者:杨奇龙

网名“北在南方”,资深 DBA,主要负责数据库架构设计和运维平台开发工作,擅长数据库性能调优、故障诊断。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


一 前言

某个客户反馈查询数据库发现 information_schema.tablesdata_free 值突发异常,达到 13G 左右。如图:

需要排查什么原因导致的,本文梳理排查的过程和和解决问题的方法。

二 排查

2.1 分析

首先 data_free 的含义是 表空间 ibd 文件经过写入和删除之后,留下的没有回收的碎片空间大小。

让现场的同学同时检查主备库,对比有没有文件大小和配置上的差异。 发现主库的data_free 值是 13G 左右, 备库正常。

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

意外从 截图的 ib

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值