MySQL 8.0+ 必须使用 binlog_expire_logs_seconds，expire_logs_days 已废弃且默认值变为0（永不清除），即使配置也无效；应设 binlog_expire_logs_seconds（如604800秒）并配合 max_binlog_size 控制磁盘增长。
MySQL 8.0+ 必须用 binlog_expire_logs_seconds，expire_logs_days 已失效
如果你在 MySQL 8.0.11 及之后版本（尤其是 8.0.23+）里还写 expire_logs_days=7，它不会报错，也不会生效——连警告都默认不显示，日志照常疯长，磁盘迟早爆掉。
根本原因是：官方从 8.0 开始彻底转向秒级精度控制，binlog_expire_logs_seconds 取代了天数制，且支持任意秒数（比如保留 3 天 6 小时 = 280800 秒），更灵活也更精确。
-
expire_logs_days在 8.0.11 起被标记为废弃，8.0.23+ 启动时会悄悄加一条 deprecation warning 到 error log（但你很可能没开日志监控，就错过了） - 它的默认值已被改为
0，即“永不清除”，和以前默认 30 天完全不同 - 如果配置文件里同时写了
expire_logs_days和binlog_expire_logs_seconds，后者生效，前者被忽略且无提示
怎么查当前生效的是哪个参数？
别猜，直接进 MySQL 查：
SHOW VARIABLES LIKE 'expire_logs_days';<br>SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
如果 binlog_expire_logs_seconds 是 NULL 或 0，说明没设或设为永不清除；如果是数值（如 604800），那就是它在管事。注意：expire_logs_days 显示的值可能是旧配置残留，不代表实际生效。
配置方式：改 my.cnf 还是动态 SET？
两种都行，但行为不同：
- 写进
/etc/my.cnf（或你的 MySQL 配置文件）的[mysqld]段里最稳妥：binlog_expire_logs_seconds = 604800（7 天）
改完必须重启 MySQL 才能生效（热加载不支持该变量） - 运行时动态设置：
SET PERSIST binlog_expire_logs_seconds = 604800;
这会写入mysqld-auto.cnf，下次启动仍有效；但若已存在冲突配置，优先级不如my.cnf - 用
SET GLOBAL临时生效（重启即丢），不推荐用于生产环境
顺手控制单个 binlog 文件大小：max_binlog_size
binlog_expire_logs_seconds 管“保留多久”，max_binlog_size 管“每个文件多大”。两者配合才能真正控住磁盘增长节奏。比如：
- 设
max_binlog_size = 512M，避免单个 binlog 文件过大导致清理延迟或备份卡顿 - 注意：这个值只是“建议上限”，InnoDB 事务不会在中间切文件，所以实际文件可能略超
- 它和过期策略无关，即使设置了
binlog_expire_logs_seconds，仍需单独配max_binlog_size
最容易被忽略的一点：MySQL 不会在运行中主动删除过期 binlog，而是在每次 binlog 切换（rotate）或实例启动时触发清理。所以哪怕你刚配好参数，也可能要等下一次 rotate 才看到磁盘空间释放。
