故障分析 | MySQL 临时表空间数据过多导致磁盘空间不足的问题排查

作者：宗杨
爱可生产品交付团队成员，主要负责公司运维平台和数据库运维故障诊断。喜爱数据库、容器等技术，爱好历史、追剧。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

一、事件背景

我们的合作客户，驻场人员报告说一个 RDS 实例出现磁盘不足的告警，需要排查。

告警信息：

告警内容：
数据库 data 磁盘不足，磁盘占用 80% 以上
数据库 binlog 磁盘不足，磁盘占用 80% 以上

二、排查过程

登陆告警的服务器，查看磁盘空间，并寻找大容量文件后，发现端口号为 4675 的实例临时表空间 ibtmp1 的大小有 955G，导致磁盘被使用了 86%；

猜测和库里执行长 SQL 有关系，产生了很多临时数据，并写入到临时表空间。

看到有这样一条 SQL，继续分析它的执行计划；

很明显看到图中标记的这一点为使用了临时计算，说明临时表空间的快速增长和它有关系。这条 SQL 进行了三表关联，每个表都有几十万行数据，三表关联并没有在 where 条件中设置关联字段，形成了笛卡尔积，所以会产生大量临时数据；而且都是全表扫描，加载的临时数据过多;还涉及到排序产生了临时数据；这几方面导致 ibtmp1 空间快速爆满。

三、解决办法

和项目组沟通后，杀掉这个会话解决问题；

但是这个 SQL 停下来了，临时表空间中的临时数据没有释放；

最后通过重启 mysql 数据库，释放了临时表空间中的临时数据，这个只能通过重启释放。

四、分析原理

通过查看官方文档，官方是这么解释的：

翻译：

根据官网文档的解释，在正常关闭或初始化中止时，将删除临时表空间，并在每次启动服务器时重新创建。重启能够释放空间的原因在于正常关闭数据库，临时表空间就被删除了，重新启动后重新创建，也就是重启引发了临时表空间的重建，重新初始化，所以，重建后的大