MySQL安装后需清理的并非缓存文件，而是tmpdir下的#sql/MY/ML/ibtmp临时文件、停服删除并重建ibtmp1、用PURGE BINARY LOGS清理binlog；严禁直接rm -rf /tmp/*或删innodb buffer pool。
MySQL安装过程本身不生成需要手动清理的“缓存文件”，真正要处理的是安装后残留的临时文件、运行时生成的临时表文件、InnoDB临时表空间（ibtmp1）以及二进制日志等——它们常被误称为“缓存”，但性质和清理方式完全不同。
查清 tmpdir 位置再动手，别直接删 /tmp
MySQL 运行中生成的临时文件（如排序、GROUP BY、临时表落盘）默认放在 tmpdir 配置指向的目录，不是所有都藏在 /tmp。直接 rm -rf /tmp/* 会误删其他进程文件，甚至破坏系统 socket 或 pid 文件。
- 先登录 MySQL 查真实路径：
SHOW VARIABLES LIKE 'tmpdir';，常见值有/tmp、/var/tmp、/data/mysql/tmp - 确认当前是否有进程正在使用这些文件：
lsof -n | grep mysql | grep "$(mysql -Nse "SELECT @@tmpdir;")"，带(deleted)后缀的才可安全删 - 只删明确属于 MySQL 的前缀文件：
#sql*（DDL 临时表）、MY*（filesort）、ML*（binlog 缓存溢出）、ibtmp*（InnoDB 临时段）
停服删 ibtmp1 是释放磁盘最有效的方式
ibtmp1 是 InnoDB 独立的临时表空间，默认自动扩展但永不收缩。跑几个月可能涨到几十 GB，而实际活跃数据可能只有几 MB。它不能在线清理，必须停机删除后由 MySQL 重建。
- 确认服务已停：
systemctl is-active mysql返回inactive才安全 - 定位文件位置：
SELECT @@datadir, @@innodb_temp_data_file_path;，通常为/var/lib/mysql/ibtmp1 - 如果启用了
innodb_temp_tablespaces_dir（MySQL 8.0.13+），还要一并清空该目录下的子目录 - 启动后 MySQL 自动创建一个约 12MB 的新
ibtmp1，无需额外配置
PURGE BINARY LOGS 才能安全清理 binlog
binlog 文件（如 mysql-bin.000001）不是临时文件，但常被当成“垃圾”直接删除——这是高危操作，会导致 mysql-bin.index 错乱、主从同步中断、GTID 不一致。
- 必须用 SQL 命令清理：
PURGE BINARY LOGS TO 'mysql-bin.000010';或PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00'; - 清理前确认没从库在拉取：
SHOW SLAVE HOSTS;和SHOW REPLICAS;（MySQL 8.0.22+） - 长期方案是配置
binlog_expire_logs_seconds = 2592000（30 天），让 MySQL 自动轮转
别碰 InnoDB Buffer Pool，它不是你能“清理”的缓存
很多人想“清缓存”其实是冲着 InnoDB 缓冲池去的，但这个内存区域由 LRU 管理，设计就是长期驻留。没有 FLUSH INNODB BUFFER POOL 这种命令，强行重启服务反而影响性能稳定性。
-
FLUSH TABLES关的是表定义缓存（Table Definition Cache），不是数据页 -
RESET QUERY CACHE在 MySQL 8.0+ 已彻底移除，执行会报错 - 真正需要干预的，是调大
tmp_table_size和max_heap_table_size，减少磁盘临时表生成
最容易被忽略的一点：很多“残留”其实来自未提交事务或卡住的 DDL。清理前先看 SHOW PROCESSLIST; 和 SELECT * FROM information_schema.INNODB_TRX;，杀掉长时间运行的连接比删文件更重要。
