接到了一台 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 参数
代码语言：javascript复制SET GLOBAL innodb_fast_shutdown = 0;
# InnoDB does a slow shutdown, a full purge and a change buffer merge before shutting down3、关闭 mysql 服务
4、删除 ibtmp1 文件
5、启动 mysql 服务
注意
为了避免以后再出现类似的情况，一定要限制临时表空间的最大值，如innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G
参数解释
在 mysql 关闭时，参数 innodb_fast_shutdown 影响着表的存储引擎为 innodb 的行为。参数为 0,1,2 三个值。
- 代表当 MYSQL 关闭时，Innodb 需要完成所有 full purge 和 merge insert buffer 操作，这需要花费时间来完成。如果做 Innodb plugin 升级，通常需要将这个参数调为 0，然后再关闭数据库
- 是参数的默认值，不需要完成 full purge 和 merge insert buffer 操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。
- 表示不需要完成 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
