MySQL临时文件分三类：tmpdir目录下运行时临时文件（如#sql前缀）、InnoDB的ibtmp1、binlog文件；清理需先停服务，分别按规则删除，严禁直接rm -rf /tmp/*。
确认临时文件在哪，别乱删
MySQL 的临时文件不只存在一个地方，tmpdir 配置决定主临时目录位置，但 InnoDB 还有独立的 ibtmp1，binlog 也会占大量空间——它们性质不同、清理方式也不同。直接 rm -rf /tmp/* 很可能误删其他进程的临时文件，甚至导致系统异常。
- 先登录 MySQL 查路径：
SHOW VARIABLES LIKE 'tmpdir';，常见值是/tmp、/var/tmp或自定义路径如/data/mysql/tmp - 检查
ibtmp1位置：SELECT @@innodb_temp_data_file_path;，默认就在数据目录（如/var/lib/mysql/ibtmp1） - binlog 文件在数据目录下，命名类似
mysql-bin.000001，不是“临时”但常被当成垃圾清理
清理 tmpdir 下的运行时临时文件
这些是排序、GROUP BY、临时表等操作生成的短生命周期文件，名字常带 #sql、mysql_tmp、ibtmp 前缀。它们本该自动删除，但崩溃或 kill 进程后容易残留。
- 必须先停服务：
sudo systemctl stop mysql（Linux）或net stop mysql（Windows） - 只删匹配前缀的文件，不删整个目录：
sudo rm -f /tmp/#sql* /tmp/mysql_tmp* /tmp/ibtmp* - 别用
rm -rf /tmp/mysql*——很多发行版把 MySQL 客户端 socket 或 pid 文件也放这儿，删了会导致启动失败 - 重启后 MySQL 不会重建这些文件，除非再次触发相关操作
重置 ibtmp1：释放被撑大的 InnoDB 临时表空间
ibtmp1 是 InnoDB 专用临时表空间，默认自动扩展但永不收缩。跑几个月可能涨到几十 GB，而实际使用可能只有几 MB。它不能在线清理，必须停机删掉让 MySQL 重建。
- 确认 MySQL 已停止：
systemctl is-active mysql返回inactive才安全 - 定位并删除：
sudo rm /var/lib/mysql/ibtmp1（路径以@@datadir和@@innodb_temp_data_file_path为准） - 启动服务：
sudo systemctl start mysql，MySQL 会自动创建一个 12MB 的新ibtmp1 - 注意：如果启用了
innodb_temp_tablespaces_dir（MySQL 8.0.13+），还要一并清理该目录下的子目录
安全清理 binlog，避免主从或恢复失效
binlog 不是临时文件，但离线环境或单机开发库长期不清理，很容易吃光磁盘。直接删文件会破坏 MySQL 的日志索引，必须用 SQL 命令或配置驱动清理。
- 登录后按文件名清理：
PURGE BINARY LOGS TO 'mysql-bin.000015';（保留编号 ≤ 000015 的日志） - 按时间清理更稳妥：
PURGE BINARY LOGS BEFORE '2026-01-01 00:00:00'; - 永久生效可加配置：
binlog_expire_logs_seconds = 2592000（30天），写入my.cnf的[mysqld]段后重启 - 切勿手动
rm mysql-bin.*——MySQL 启动时会报错Could not open log file，且无法启动
真正麻烦的不是“怎么删”，而是删完发现服务起不来、连接不上、或者某张表突然打不开——因为删错了路径、漏了权限、或没停干净进程。每次清理前，至少确认三件事：systemctl status mysql 显示 inactive、ps aux | grep mysql 无残留进程、ls -l 看目标路径是否真属于 MySQL。临时文件这东西，宁可多查一次，也不愿重装一遍。
