接到了一台 MySQL5.7 服务器磁盘空间不足的报警，该业务的数据量 20G 的样子，是什么造成磁盘空间不足呢？

经过排查后发现，数据目录下面有一个 ibtmp1 的文件特别大，有 949G 。

ibtmp1 是个什么东西呢？查看官方文档后发现这是非压缩的 innodb 临时表的独立表空间。通过 innodb_temp_data_file_path 参数指定文件的路径，文件名和大小，默认配置为 ibtmp1:12M:autoextend，也就是说在支持大文件的系统这个文件大小是可以无限增长的。

解决办法

1、修改 my.cnf 配置文件：

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G

2、设置 innodb_fast_shutdown 参数

SET GLOBAL innodb_fast_shutdown = 0; 
# InnoDB does a slow shutdown, a full purge and a change buffer merge before shutting down

3、关闭 mysql 服务

4、删除 ibtmp1 文件

5、启动 mysql 服务

注意

为了避免以后再出现类似的情况，一定要限制临时表空间的最大值，如innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G

参数解释

在 mysql 关闭时，参数 innodb_fast_shutdown 影响着表的存储引擎为 innodb 的行为。参数为 0,1,2 三个值。

1. 代表当 MYSQL 关闭时，Innodb 需要完成所有 full purge 和 merge insert buffer 操作，这需要花费时间来完成。如果做 Innodb plugin 升级，通常需要将这个参数调为 0，然后再关闭数据库
2. 是参数的默认值，不需要完成 full purge 和 merge insert buffer 操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。
3. 表示不需要完成 full purge 和 merge insert buffer 操作 ，也不将缓冲池中的数据脏页写回磁盘，。而是将日志都写入日志文件。这样不会有任何事物丢失，但是 mysql 在下次启动时，会执行恢复操作（recovery）

如果在上次关闭 innodb 的时候是在 innodb_fast_shutdown=2 或是 mysql crash 这种情况，那么它会利用 redo log 重做那些已经提交了的事务。
接下来的操作过程是：
(1). Rollback uncompleted transitions 取消那些没有提交的事务
(2). Purge all 清除无用的undo页
(3). Merge insert buffer 合并插入缓冲

via:
https://blog.csdn.net/weixin_34358365/article/details/89822725
https://blog.csdn.net/edyf123/article/details/81026139