MySQL 8.0 中 expire_logs_days 已弃用且无效，必须使用 binlog_expire_logs_seconds 和 binlog_expire_logs_auto_purge 配置并确认其生效，否则无法自动清理 binlog。
expire_logs_days 在 MySQL 8.0 中不能用于自动清理 binlog——它已被弃用，设了也不生效，还可能引发错误或掩盖真实问题。
查 binlog_expire_logs_seconds 是否真正生效
很多人的配置文件里写了 expire_logs_days = 7，重启后以为万事大吉，结果磁盘照涨。根本原因是：
- MySQL 8.0.11+ 默认把
expire_logs_days当作兼容占位符，值恒为 0（即永不清除） - 若同时配置了
binlog_expire_logs_seconds和expire_logs_days，MySQL 8.0.23+ 会直接报错ERROR 3683 (HY000)，拒绝启动
必须进 MySQL 执行以下三行命令确认真实状态：SHOW VARIABLES LIKE 'log_bin'; —— 必须返回 ON，否则压根没开 binlogSHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; —— 值必须是非零正整数（如 604800），若为 0 或空，说明自动清理被禁用SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge'; —— 必须是 ON，否则即使秒数设对了，也不会删任何文件
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
配置文件里写 expire_logs_days 是危险操作
- 不要再往
/etc/my.cnf或/www/server/mysql/etc/my.cnf的[mysqld]段里加expire_logs_days = 7 - 如果已有，建议立刻清掉：
SET GLOBAL expire_logs_days = 0;，避免和新参数冲突 - 真正该写的只有：
binlog_expire_logs_seconds = 604800（7 天）和binlog_expire_logs_auto_purge = ON - 注意拼写：少一个
s（比如binlog_expire_log_seconds）会导致静默失败，SHOW VARIABLES仍显示默认值
PURGE BINARY LOGS 手动清理前必须核对从库位置
配置只管“未来生成的日志”，已堆积的几十个 mysql-bin.000xxx 文件不会自动消失。手动清理时：
- 先在每个从库执行
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File字段 - 取所有从库中该字段的最早序号（例如
mysql-bin.000120）作为安全下限 - 主库执行：
PURGE BINARY LOGS TO 'mysql-bin.000120';（注意：不删.000120本身） - 绝对不要用
RESET MASTER，它会重置序列号，导致所有从库同步中断
真正容易被忽略的是：binlog_expire_logs_seconds 只对「非当前活跃」的 binlog 生效；而 max_binlog_size 控制单文件大小，两者不配着用，就可能出现单个日志文件过大、轮转不及时、清理延迟等问题。
