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，否则压根没开 binlog
SHOW 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 控制单文件大小，两者不配着用，就可能出现单个日志文件过大、轮转不及时、清理延迟等问题。