第一件事是确认slow_query_log是否开启且正在写入：执行SHOW VARIABLES LIKE 'slow_query_log'和SHOW VARIABLES LIKE 'slow_query_log_file'，若值为ON且文件路径指向超大日志，则证实问题源头；切勿直接rm，应先SET GLOBAL slow_query_log = 'OFF'再清空内容。
确认 slow_query_log 是否正在写入
磁盘被慢日志吃满时，第一件事不是删文件，而是看它还在不在写。如果 slow_query_log 还开着，你删了文件，MySQL 会继续往已删除的 inode 写数据，df -h 显示空间不释放，du -sh 却找不到大文件——典型的“假清理”。
登录 MySQL 执行：
SHOW VARIABLES LIKE 'slow_query_log';<br>SHOW VARIABLES LIKE 'slow_query_log_file';
如果 slow_query_log 值是 ON，且 slow_query_log_file 指向一个超大文件（比如 /data/mysql/logs/mysql-slow.log），那就坐实了问题源头。
常见误判点：
- 误以为
ls -lh看到文件大小没变，就代表没在写——错。MySQL 可能正以追加模式持续写入 - 用
tail -f看不到新内容，就认为日志停了——错。log_queries_not_using_indexes=1开着时，大量轻量级无索引查询也会刷日志，肉眼难察觉
快速止血：关日志 + 清空内容（不是 rm）
生产环境禁止直接 rm -f mysql-slow.log。正确姿势是先让 MySQL 停写，再清空文件内容。
执行：
SET GLOBAL slow_query_log = 'OFF';<br>SELECT SLEEP(1); -- 确保写入缓冲落盘<br>echo '' > /data/mysql/logs/mysql-slow.log
注意路径要和 slow_query_log_file 值严格一致。清空比删除更安全，因为：
- 文件句柄仍被 mysqld 持有，清空后空间立即释放（
df和du同步更新） - 后续重启或重新开启日志时，MySQL 会自动重建该文件，不会报错
- 万一误操作，还能从清空前的备份里恢复日志片段
别跳过 SET GLOBAL 这步——有些 DBA 直接清空，结果发现几分钟后文件又开始涨，就是因为日志根本没关。
查配置：log_queries_not_using_indexes 是真凶
很多慢日志爆炸不是因为 long_query_time 设太低，而是因为 log_queries_not_using_indexes = 1 被打开了。
这个参数会让所有未走索引的 SQL 都进慢日志，哪怕执行只花了 0.01 秒。业务表没建好索引、ORM 自动生成的 SELECT *、临时调试语句，全都会塞进来。
检查方法：
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';
如果是 ON，且业务 QPS 高，基本就是它在狂写。临时关闭：
SET GLOBAL log_queries_not_using_indexes = 'OFF';
但注意：这不能替代调优。真正要做的，是结合 mysqldumpslow -s t 或解析日志找高频无索引查询，补上缺失索引，而不是长期靠关参数苟活。
永久治理：轮转 + 阈值 + 监控
清完这次，不代表下次不爆。必须做三件事：
- 在
my.cnf的[mysqld]段里加：slow_query_log = 1、long_query_time = 1（别设 0 或 2）、log_queries_not_using_indexes = 0 - 配日志轮转：Linux 上用
logrotate，每周 rotate 一次，保留 4 周，压缩归档。避免单个文件无限增长 - 加监控项：对
slow_query_log_file所在目录做du -sh定时采集，超过 5GB 就告警——别等 397G 才发现
最常被忽略的一点：slow_query_log_file 路径不能和 datadir 共用一个磁盘分区。一旦慢日志暴涨，可能直接卡死数据库写入。把它挪到独立日志盘，是成本最低的容灾手段。
