如何在MySQL配置文件中设置自动删除过期二进制日志的天数？-mysql教程-PHP中文网

mysql 5.7+ 使用 expire_logs_days 自动清理 binlog 需在 my.cnf 的 [mysqld] 段配置 expire_logs_days = 7 并重启服务才永久生效；该参数单位为天，设为 0 表示禁用自动清理，且仅在 mysql 启动或 binlog 切换（如 flush logs）时触发清理，非实时执行。

如何在mysql配置文件中设置自动删除过期二进制日志的天数？

MySQL 5.7+ 怎么用 `expire_logs_days` 自动清理 binlog？

MySQL 5.7 及更早版本只支持 expire_logs_days 这个参数，它控制二进制日志保留天数。但要注意：这个参数是动态变量，修改后需重启 mysqld 才生效（5.7 默认不生效），且单位是“天”，不是小时或秒。

在 my.cnf 的 [mysqld] 段下添加：expire_logs_days = 7
必须重启 MySQL 服务才能启用该设置，SET GLOBAL expire_logs_days = 7 在 5.7 中仅临时生效，重启即丢失
该值设为 0 表示禁用自动清理（binlog 永不删除），生产环境不建议
实际清理由后台线程触发，通常在每天凌晨执行，不是实时删除

MySQL 8.0+ 推荐用 `binlog_expire_logs_seconds`

8.0.11 起废弃了 expire_logs_days，改用更精确的 binlog_expire_logs_seconds（单位：秒）。它支持动态修改，无需重启，也兼容小数精度（比如 3.5 天 = 302400 秒）。

配置方式：binlog_expire_logs_seconds = 604800（即 7 天）
可在线设置：SET GLOBAL binlog_expire_logs_seconds = 604800，立即生效
如果同时设置了 expire_logs_days 和 binlog_expire_logs_seconds，后者优先
注意：该变量受 super_read_only 影响，开启时无法 SET GLOBAL 修改

为什么 `PURGE BINLOGS` 有时不按配置清理？

即使配置了过期参数，也可能发现磁盘上 binlog 还在增长——常见原因不是配置失效，而是被复制或备份进程持有。

Pandas 配置文件报告生成器

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

主从复制中，如果从库还没读完某个 binlog 文件，MySQL 不会删除它（SHOW MASTER LOGS 中 File_size 非零不代表可删）
运行 SHOW SLAVE STATUS\G 查看 Relay_Master_Log_File，确认从库已追平；或检查 SELECT @@global.gtid_executed 是否覆盖所有 binlog GTID
Percona XtraBackup、mydumper 等工具若正在备份，会调用 FLUSH LOGS 并隐式延长保留窗口
PURGE BINLOGS TO 'mysql-bin.000123' 或 PURGE BINLOGS BEFORE '2024-01-01 00:00:00' 是手动强制清理，但需确保目标文件未被依赖

清理前务必确认 binlog 是否还在被使用

误删 binlog 可能导致主从断裂、GTID 丢失、无法恢复到某时间点。最稳妥的做法是先查依赖，再清理。

查当前最小需要的 binlog：SHOW MASTER LOGS; + SELECT * FROM performance_schema.replication_applier_status_by_coordinator;
查 GTID 范围：SELECT @@global.gtid_purged;，确保要删的 binlog 不包含其中任何事务
备份前执行 FLUSH BINARY LOGS，让新日志及时切出，避免大文件卡住清理逻辑
监控 binlog 目录磁盘占用，比单纯看天数更可靠——某些业务高峰可能一天生成几十 GB，7 天就撑爆磁盘

配置本身很简单，真正容易出问题的是没验证依赖关系，或者把 expire_logs_days 当成实时开关。MySQL 不会因为过了设定天数就立刻删文件，它只在满足安全前提时才动手。