必须设置binlog自动清理，否则磁盘迟早被撑爆；应结合业务恢复窗口、主从延迟和磁盘余量设定，且需确保配置正确、服务重启、最老binlog超期且从库无依赖才真正生效。
默认不设就是永不清除，磁盘迟早被撑爆。必须设，且要结合业务恢复窗口、主从延迟、磁盘余量三者来定。
查看当前 expire_logs_days 是否生效
直接查变量最可靠，别信配置文件没重启就生效：
mysql> show variables like 'expire_logs_days';
如果返回 Value 是 0，说明实际没启用自动清理——哪怕你改过 my.cnf 但没重启 MySQL，或写错了 section（必须在 [mysqld] 下）。
-
0：永不自动删除，风险最高 -
7：常见起点，适合多数中小业务 -
30：金融、核心系统建议值，但需确认磁盘能扛住
MySQL 5.7 和 8.0+ 的参数差异
5.7 只认 expire_logs_days，单位是“天”；8.0+ 多了个更精确的 binlog_expire_logs_seconds，单位是“秒”。两者互斥，binlog_expire_logs_seconds 优先级更高。
- 5.7 写配置：
expire_logs_days = 7 - 8.0+ 推荐写：
binlog_expire_logs_seconds = 604800（7 天） - 动态设置时注意语法：
SET GLOBAL expire_logs_days = 7或SET GLOBAL binlog_expire_logs_seconds = 604800
别混用，否则后者会覆盖前者，但只在 8.0+ 生效。
为什么 flush logs 后 binlog 没立刻删
MySQL 不是按“文件创建时间”删，而是扫描 bin.index 里最老的文件，看它的操作系统修改时间（mtime）是否超期。只要最老那个还“新鲜”，哪怕中间有文件已超期，也不会动。
- 执行
flush logs只是切新文件，不触发清理 - 清理实际发生在 MySQL 启动时、或下次
flush logs时、或每小时左右的后台检查中 - 想立刻清理？用
purge binary logs before '2026-08-04 00:00:00'，但务必确认从库已拉完
磁盘快满了，但 expire_logs_days 设了还是涨
两个常见原因：一是 max_binlog_size 太小（比如设成 100M），导致频繁切文件，bin.index 里堆了一堆小文件，清理逻辑卡在第一个没超期的文件上；二是主从延迟大，从库还在读旧 binlog，MySQL 不敢删。
- 查当前最大单文件大小：
show variables like 'max_binlog_size';，建议设为1073741824（1G）以上 - 查从库延迟：
show slave status\G看Seconds_Behind_Master - 云数据库（如腾讯云、阿里云）还要看控制台里的“本地 binlog 保留小时数”，它和
expire_logs_days是两套机制，可能冲突
真正起效前，得同时满足：配置写对 + MySQL 重启 + 最老 binlog 文件确实超期 + 从库不依赖它 —— 少一个，磁盘就继续涨。
