执行 PURGE BINARY LOGS 前必须确认主从状态，否则可能引发从库中断或数据丢失；需先查主库 SHOW MASTER STATUS 的 File 值及各从库 SHOW REPLICA STATUS 的 Relay_Master_Log_File，取最大序号文件作为安全删除边界，仅可删其之前文件。
执行 PURGE BINARY LOGS 命令前必须确认主从状态
直接运行 PURGE BINARY LOGS 可能导致从库中断或数据丢失，尤其在主从架构中。MySQL 不会自动校验你指定的文件是否仍在被从库读取，它只按索引删除——删完就真没了。
必须先查清主库和所有从库当前依赖的 binlog 文件：
- 主库执行
SHOW MASTER STATUS，看File字段（如mysql-bin.000022），这是最新正在写的文件，不能删 - 每个从库执行
SHOW SLAVE STATUS\G，重点关注Relay_Master_Log_File（主库上该从库尚未执行完的最后一个事件所在文件） - 取所有从库
Relay_Master_Log_File中序号最大的那个（比如mysql-bin.000018），你只能安全删除比它更旧的文件
PURGE BINARY LOGS 的两种写法及风险差异
PURGE BINARY LOGS TO 和 PURGE BINARY LOGS BEFORE 行为不同，选错容易误删：
-
PURGE BINARY LOGS TO 'mysql-bin.000018'：删除 所有序号小于000018的文件（即000001到000017），000018本身保留 -
PURGE BINARY LOGS BEFORE '2026-04-28 00:00:00'：删除 最后修改时间早于该时间 的所有文件。注意：这个“最后修改时间”是 binlog 文件本身的 mtime，不是里面事件的时间戳，且 MySQL 实际用的是文件头里记录的created时间，可能和系统时间有偏差 - 推荐优先用
TO写法——更确定、不依赖系统时钟，也避免因时区或 NTP 同步问题导致误判
为什么 set global expire_logs_days=7 有时不生效
设置 expire_logs_days 是自动清理的常用方式，但它只在特定时机触发：
- MySQL 5.7 及以前：仅在
FLUSH LOGS、重启、或 binlog 文件大小达到max_binlog_size触发轮转时，才检查并删除过期日志 - MySQL 8.0+：改用
binlog_expire_logs_seconds（单位秒），逻辑相同，但精度更高；仍需日志轮转作为触发点 - 如果业务写入极低（比如每天只有几条 INSERT），binlog 文件长期不翻页，过期日志就一直堆着不删
- 临时设置
SET GLOBAL expire_logs_days = 7后，建议手动执行一次FLUSH BINARY LOGS加速清理
reset master 的真实影响与适用场景
RESET MASTER 会清空所有 binlog 并重置序号为 mysql-bin.000001，但它不是“安全清理”手段：
- 仅适用于无从库、无备份恢复需求、且确认不需要任何历史变更记录的测试或开发环境
- 生产环境只要存在从库，执行后从库会报错
Could not find first log file name in binary log index file，同步彻底中断 - 即使没有从库，
RESET MASTER也会让基于时间点或位置点的恢复完全失效——因为所有历史 offset 都消失了 - 真正需要“归零”时，应先用
PURGE清到某个安全点，再FLUSH BINARY LOGS手动切新文件，而非暴力RESET
最易被忽略的一点：PURGE 操作本身会被记录进新的 binlog，如果你刚 purge 完一批日志，紧接着又执行了 DML，这些操作会写入下一个 binlog 文件——所以 purge 后立刻 SHOW BINARY LOGS 看到的文件数可能没变，只是旧文件被删、新文件已开始写入。别只盯着数量，要核对 Log_name 序号是否连续跳变。
