mysql日志需分策略管理：binlog在8.0.23+用binlog_expire_logs_seconds，旧版本用expire_logs_days；error log必须依赖logrotate配合kill -usr1；slow/general log开启后须外部轮转或定期清理。
MySQL日志不自动清理，磁盘迟早被撑爆——这不是危言耸听，而是生产环境里最常踩的坑之一。关键不是“要不要设”，而是“设对没设对”，尤其 binlog 和 error log 的处理逻辑完全不同，混用一套策略必出问题。
binlog 保留天数怎么设才真正生效
别只改 expire_logs_days 就以为完事了。MySQL 8.0.23+ 已弃用它，改用 binlog_expire_logs_seconds，否则配置无效但不报错，日志照常堆积。
- MySQL 8.0.23 及以上：在
my.cnf的[mysqld]段写binlog_expire_logs_seconds = 604800（7 天），然后执行SET PERSIST binlog_expire_logs_seconds = 604800;动态生效且持久化 - MySQL 5.7 / 8.0.22 及以前：用
expire_logs_days = 7，但必须重启 MySQL 或执行SET GLOBAL expire_logs_days = 7;+FLUSH LOGS; -
max_binlog_size是单个文件上限（默认 1GB），设太小会导致频繁切换文件，增加PURGE开销；设太大则单个文件难管理，建议保持默认或调到512M - 手动清理别只信
PURGE BINARY LOGS BEFORE '2024-01-01'，时间格式必须是服务器本地时区，且该语句不校验时间有效性，输错也不会报错
error log 必须靠 logrotate，MySQL 自己不管轮转
MySQL 启动后一直往同一个 error.log 文件追加，不发信号它绝不会切新文件。指望 log_error 配置项自动轮转？不存在的。
- 创建
/etc/logrotate.d/mysql，内容示例：/var/lib/mysql/*.err { daily rotate 7 missingok compress delaycompress notifempty create 640 mysql mysql sharedscripts postrotate if [ -f /var/run/mysqld/mysqld.pid ]; then kill -USR1 `cat /var/run/mysqld/mysqld.pid` fi endscript } -
kill -USR1是关键：告诉 mysqld 关闭当前 error log 并打开新文件，否则 logrotate 重命名后 MySQL 还在往旧文件句柄写，新日志永远为空 - 确认
log_error指向的是绝对路径（如/var/lib/mysql/hostname.err），不能是相对路径或符号链接，否则logrotate找不到目标
slow log 和 general log 别开着玩，开了就得管
这两个日志默认关闭，一旦开启就按秒级产生大量文本，尤其 general_log 记所有查询，QPS 高时磁盘 I/O 直接拉满。
- 启用前先评估必要性：
slow_query_log = 1+long_query_time = 2足够定位慢 SQL；general_log = 1只应在排查连接异常等极短期场景用 - 它们不支持内置过期机制，必须配合外部轮转：
logrotate配置中加上对应路径（如/var/lib/mysql/slow.log），并确保postrotate里触发FLUSH SLOW LOGS（MySQL 8.0.23+）或重启 MySQL - 如果用
TABLE方式存储（slow_query_log_file指向表），记得定期TRUNCATE TABLE mysql.slow_log，否则表体积持续膨胀
最容易被忽略的点：所有日志路径权限必须为 mysql:mysql，且 logrotate 脚本里 create 行的用户组要匹配；另外，PURGE BINARY LOGS 和 FLUSH LOGS 都需要 REPLICATION CLIENT 权限，普通应用账号执行会静默失败。
