应先确认日志是否必要，再临时或永久关闭；若需保留则调高long_query_time；清理时清空文件内容并压缩归档，推荐用logrotate配合copytruncate实现安全轮转。
mysql slow_log 和 general_log 文件暴涨，磁盘快满了怎么办
直接停掉日志、删文件不是办法——slow_log 和 general_log 一旦开启，MySQL 会持续追加写入，不自动轮转，也不压缩。你看到的几十 GB 日志文件，往往只是单个未切割的文本，rm 之后如果日志还在写，可能瞬间又占满空间，甚至因 I/O 阻塞拖慢主库。
如何安全关闭或限制日志写入频率
先确认当前是否真在用这些日志：很多线上环境其实并不需要 general_log（记录所有 SQL），而 slow_log 也常因 long_query_time 设得太低（比如 0 或 1）导致全量记录。
-
SHOW VARIABLES LIKE 'slow_query_log';和SHOW VARIABLES LIKE 'general_log';查开关状态 - 临时关闭：
SET GLOBAL slow_query_log = 'OFF';（重启失效）或SET GLOBAL general_log = 'OFF'; - 永久关闭：修改
my.cnf，删掉或注释掉slow_query_log = 1和general_log = 1行 - 若必须保留
slow_log，把long_query_time调高到 2–5 秒（SET GLOBAL long_query_time = 3;），避免记录大量无意义短查询
已有大日志文件怎么清理又不丢关键信息
别直接 rm -f 正在被 MySQL 写入的日志文件——Linux 下文件被进程打开后，即使删了，磁盘空间也不会释放，直到 MySQL 重启或重开日志句柄。更稳妥的是“清空内容 + 压缩归档”。
- 查日志路径：
SHOW VARIABLES LIKE 'slow_query_log_file';或SHOW VARIABLES LIKE 'general_log_file'; - 清空当前文件（不删）：
echo '' > /var/lib/mysql/slow.log（路径以实际为准），前提是已确认 MySQL 进程仍持有该文件句柄 - 压缩历史日志：
gzip /var/lib/mysql/slow.log.20240401，压缩率通常达 90%+，且zcat可随时查看 - 加个简单定时任务归档（例如每天凌晨）：
mv /var/lib/mysql/slow.log /var/lib/mysql/slow.log.$(date +\%Y\%m\%d) && gzip /var/lib/mysql/slow.log.$(date +\%Y\%m\%d)
想自动轮转又不想换工具？用 logrotate 最省心
MySQL 自身不支持日志轮转，但系统级 logrotate 完全能接管。关键是配置好 copytruncate ——它会在复制后立刻截断原文件，不中断 MySQL 写入。
- 新建
/etc/logrotate.d/mysql-slow：
/var/lib/mysql/slow.log {
daily
missingok
rotate 7
compress
delaycompress
copytruncate
notifempty
}
logrotate -d /etc/logrotate.d/mysql-slow（-d 是 debug 模式）logrotate 运行用户（通常是 root）对日志文件有读写权，否则 copytruncate 会失败最常被忽略的一点：logrotate 默认按文件大小或时间触发，但如果你的慢日志一天只写几 KB，它可能永远不轮转；反过来，如果某天突发大量慢查，单日就涨到 5 GB，daily 就不够用了。这时候得加 size 100M 或改用 hourly，具体看业务毛刺节奏。
