作者：宗杨
爱可生产品交付团队成员，主要负责公司运维平台和数据库运维故障诊断。喜爱数据库、容器等技术，爱好历史、追剧。
本文来源：原创投稿*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
一、事件背景
我们的合作客户，驻场人员报告说一个RDS实例出现磁盘不足的告警，需要排查。
告警信息：
告警内容：
数据库data磁盘不足，磁盘占用80%以上
数据库binlog磁盘不足，磁盘占用80%以上
二、排查过程
登陆告警的服务器，查看磁盘空间，并寻找大容量文件后，发现端口号为的实例临时表空间ibtmp1的大小有G，导致磁盘被使用了86%；
猜测和库里执行长SQL有关系，产生了很多临时数据，并写入到临时表空间。
看到有这样一条SQL，继续分析它的执行计划；
很明显看到图中标记的这一点为使用了临时计算，说明临时表空间的快速增长和它有关系。这条SQL进行了三表关联，每个表都有几十万行数据，三表关联并没有在where条件中设置关联字段，形成了笛卡尔积，所以会产生大量临时数据；而且都是全表扫描，加载的临时数据过多;还涉及到排序产生了临时数据；这几方面导致ibtmp1空间快速爆满。
三、解决办法
和项目组沟通后，杀掉这个会话解决问题；
但是这个SQL停下来了，临时表空间中的临时数据没有释放；
最后通过重启mysql数据库，释放了临时表空间中的临时数据，这个只能通过重启释放。
四、分析原理
通过查看官方文档，官方是这么解释的：
翻译：
根据