expire_logs_days在MySQL 5.7+中控制binlog保留天数，默认0表示永不过期；MySQL 8.0+应优先使用binlog_expire_logs_seconds（秒级精度），二者不可共存，且清理仅触发于FLUSH LOGS或重启时。
expire_logs_days 是最直接控制 binlog 保留天数的参数，但必须注意：它只在 MySQL 5.7 及以上版本生效，且默认值为 0（永不过期），不设等于放任磁盘被撑爆。
怎么查当前 binlog 保留天数设置？
直接执行：SHOW VARIABLES LIKE 'expire_logs_days';
如果返回 Value 是 0，说明没启用自动清理——这不是“保留 0 天”，而是“永不删除”。
临时改和永久改的区别在哪？
临时修改用 SET GLOBAL expire_logs_days = 7;，立刻生效，但 MySQL 重启就丢；
永久生效必须写进配置文件（如 /etc/my.cnf 或 /etc/mysql/my.cnf）的 [mysqld] 段里：
[mysqld] expire_logs_days = 7
改完要重启服务：
systemctl restart mysql（或 service mysqld restart）。
MySQL 8.0+ 推荐用 binlog_expire_logs_seconds
这个参数比 expire_logs_days 更精确，单位是秒，支持小数天（比如 3.5 天 = 302400 秒）。
- 查看当前值：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; - 临时设置：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7 天） - 永久设置：在
[mysqld]下加一行binlog_expire_logs_seconds = 604800
binlog_expire_logs_seconds 和 expire_logs_days 不能同时设，MySQL 会优先用前者（8.0+），后者会被忽略。删 binlog 不靠等，得主动触发清理时机
即使设置了 expire_logs_days，MySQL 也不会每秒扫描一遍文件。它只在两个时刻真正清理：
- 每次执行 FLUSH LOGS（手动滚动日志）
- MySQL 启动时
所以如果你刚改了保留天数，又不想等重启，就手动跑一次：FLUSH LOGS;
另外，PURGE BINARY LOGS BEFORE '2026-08-04 00:00:00'; 这类命令是即时生效的，但风险高——删错可能断主从或丢恢复点。
实际运维中容易忽略的是：MySQL 判断 binlog 是否过期，依据的是文件的操作系统修改时间（mtime），不是日志里事务的时间戳。这意味着如果某天没写入、日志文件没更新，那它就不会被判定为“过期”，哪怕逻辑上已超期。所以别只盯着参数，得配合监控 ls -lt /var/lib/mysql/ | grep bin 看真实文件状态。
