mysql 8.0的binlog_expire_logs_seconds是控制binlog保留时间的秒级精度参数，取代已弃用的天粒度expire_logs_days；它支持小时/分钟级策略、跨时区一致、事件触发清理且优先级更高，避免日志无限堆积。
MySQL binlog_expire_logs_seconds 是什么，为什么它比 expire_logs_days 更关键
MySQL 8.0.28 及以后版本中，binlog_expire_logs_seconds 已取代 expire_logs_days 成为控制二进制日志保留时间的首选配置项。前者以秒为单位，精度更高；后者仅支持天粒度（且已标记为 deprecated）。如果你在 8.0.28+ 环境下仍用 expire_logs_days，MySQL 不会报错，但实际不会生效——日志可能无限堆积。
实操建议：
- 确认 MySQL 版本：
SELECT VERSION();，若 ≥ 8.0.28，优先设binlog_expire_logs_seconds - 该变量是动态可调的，无需重启：
SET GLOBAL binlog_expire_logs_seconds = 259200;（即 3 天） - 写入配置文件时，必须放在
[mysqld]段下，例如：binlog_expire_logs_seconds = 604800
- 注意：若同时设置了
expire_logs_days和binlog_expire_logs_seconds，后者优先级更高
手动清理 binlog 前，先看清楚当前状态和依赖关系
直接 PURGE BINLOGS 很快，但容易误删正在被复制或备份工具读取的日志。执行前务必检查：
- 查当前所有 binlog：
SHOW BINARY LOGS;，注意File_size列，小尺寸文件可能是刚切换的空日志 - 查复制位点（主从场景）：
SHOW SLAVE STATUS\G，关注Relay_Master_Log_File和Exec_Master_Log_Pos，确保不删掉从库还没读完的日志 - 查 GTID 集合（若启用 GTID）：
SELECT @@global.gtid_executed;，PURGE不能删掉其中包含的任何事务所对应的 binlog - 查备份工具依赖：Percona XtraBackup、mydumper 等通常会在备份结束时记录
binlog filename + position，删之前核对备份元数据
PURGE BINLOGS 的两种安全用法：按时间 vs 按文件名
按时间清理看似直观，但 MySQL 实际按 binlog 文件头部的时间戳判断，而该时间戳是文件创建时刻（不是最后写入时间），在高负载下可能偏差数分钟。更稳妥的是按文件名清理：
- 按文件名清理（推荐）：
PURGE BINLOGS TO 'mysql-bin.000123';—— 保留包括000123及之后的所有日志，删掉之前的 - 按时间清理（需谨慎）：
PURGE BINLOGS BEFORE '2024-05-20 00:00:00';—— MySQL 会找第一个文件头时间 ≥ 该时间点的文件，然后删掉它前面全部文件；若没有文件满足条件，则不删任何内容 - 执行后立即验证：
SHOW BINARY LOGS;看是否符合预期，尤其注意最老文件的File名和File_size - 不要在业务高峰执行
PURGE，该操作会加全局锁（虽短暂），可能阻塞 DDL 或大事务提交
监控 binlog 增长异常，避免磁盘被打爆
即使设置了 binlog_expire_logs_seconds，也可能因以下原因导致日志暴增：
- 主库长时间无写入：binlog 不会自动滚动，旧文件无法过期（因为没新文件触发清理逻辑），需手动
FLUSH LOGS强制切换 - 从库延迟严重：主库会保留从库尚未读取的日志，
SHOW SLAVE STATUS中Seconds_Behind_Master超大时要警惕 - 开启了
binlog_row_image = FULL且频繁更新大字段：每行变更都记完整镜像，日志体积激增 - 监控建议：用
du -sh /var/lib/mysql/mysql-bin.*定期统计，或查information_schema.INNODB_METRICS中log_writes指标趋势
真正难处理的不是“怎么删”，而是“为什么删不掉”——往往卡在复制延迟、GTID 范围锁定或备份工具未释放位点上。每次清理前花两分钟看一眼 SHOW SLAVE STATUS 和 SELECT @@global.gtid_executed;，能避开 80% 的线上事故。
