MySQL 8.0.11+ 必须用 binlog_expire_logs_seconds，expire_logs_days 已失效且默认为0；确认生效参数需执行 SHOW GLOBAL VARIABLES LIKE 'expire_logs_days'、SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_seconds' 和 SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_auto_purge'，其中 binlog_expire_logs_seconds 为非零值且 binlog_expire_logs_auto_purge 为 ON 时才真正生效。
MySQL 8.0.11+ 必须用 binlog_expire_logs_seconds，expire_logs_days 已失效且默认为 0（永不清除），配了也白配。
怎么确认当前生效的是哪个参数？
别猜，直接查：
SHOW GLOBAL VARIABLES LIKE 'expire_logs_days';<br>SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_seconds';<br>SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_auto_purge';
关键看三个值：
-
binlog_expire_logs_seconds是非零数值（比如604800）→ 它在管事 -
binlog_expire_logs_auto_purge是OFF→ 即使设了秒数也**不会删日志** -
expire_logs_days显示非零值？可能是旧配置残留，不代表生效
配置方式：写配置文件 vs 动态 SET
写进 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 的 [mysqld] 段最可靠：
[mysqld]<br>binlog_expire_logs_seconds = 604800<br>binlog_expire_logs_auto_purge = ON
注意：
- 改完不重启 MySQL 也能生效，但必须执行
FLUSH BINARY LOGS才会立刻触发清理 - 漏掉
[mysqld]段、拼错参数名（如binlog_expire_log_seconds少个s）→ 静默失败，SHOW VARIABLES仍显示默认值 - 用
SET PERSIST binlog_expire_logs_seconds = 604800会写入mysqld-auto.cnf，但若my.cnf里有冲突项，优先级更低
PURGE 命令为什么没反应？
常见错觉：设了 binlog_expire_logs_seconds 就该立刻删文件。实际不是：
- MySQL 不靠定时任务清理，而是在启动、
FLUSH BINARY LOGS、或max_binlog_size触发轮转时顺带扫描过期文件 - 所以配完不
FLUSH，可能等一小时才看到效果 - 如果磁盘告急，别等自动，直接手动
PURGE BINARY LOGS BEFORE '2026-06-05 00:00:00'或PURGE BINARY LOGS TO 'mysql-bin.000042' - 主从环境下，删之前务必核对从库的
Relay_Master_Log_File，否则 I/O 线程报Could not find first log file name in binary log index file
真正容易被忽略的点是 binlog_expire_logs_auto_purge 默认虽为 ON，但某些 Docker 镜像或云数据库托管服务会默认关掉它——光设秒数没用，得一起确认这个开关开着。
