必须用PURGE BINARY LOGS命令删除binlog，不可直接rm；删前须查从库Relay_Master_Log_File确定安全边界，仅可删其序号更小的文件，且不能删主库当前正在写的文件。
不能直接用 rm 删除 binlog 文件，否则 mysql-bin.index 不同步，后续 SHOW BINARY LOGS 会报错或漏显，主从复制也可能中断。
确认哪些 binlog 还能安全删
清理前必须知道「哪些文件已不再被任何从库依赖」。重点不是主库当前写到哪，而是从库读到了哪：
- 登录从库，执行
SHOW SLAVE STATUS\G，看Relay_Master_Log_File字段（不是Master_Log_File）——它表示该从库已成功执行到主库的哪个 binlog 文件 - 回到主库，执行
SHOW BINARY LOGS，找出序号小于Relay_Master_Log_File的所有文件（比如从库显示mysql-bin.000126，那.000125及更早的都可删） - 如果没搭从库，或确定不需要主从恢复，也要至少保留
SHOW MASTER STATUS显示的当前正在写的那个文件（如mysql-bin.000127），不能删它
用 PURGE BINARY LOGS 安全删除
MySQL 提供的 PURGE 命令才是唯一安全的手动清理方式，它会同时更新 mysql-bin.index 并通知内核释放句柄：
- 按文件名删（推荐）：
PURGE BINARY LOGS TO 'mysql-bin.000126';—— 删除所有 早于 该文件的日志（不含本文件） - 按时间删（需注意时区）：
PURGE BINARY LOGS BEFORE '2026-06-25 00:00:00';—— 时间格式必须是'YYYY-MM-DD HH:MM:SS'，不支持函数表达式如NOW() - INTERVAL 7 DAY - 执行后立即生效，但磁盘空间可能不会立刻释放：用
lsof | grep 'deleted' | grep mysql查是否有残留句柄；若存在，等下次FLUSH BINARY LOGS或重启 mysqld 才真正回收
删完发现空间没变？别急着重装MySQL
常见现象是 df -h 看磁盘仍 100%，但 PURGE 已执行成功。这不是命令失败，而是 Linux 的文件句柄机制导致：
- MySQL 进程仍在持有已删除 binlog 的文件句柄（
lsof可验证） - 此时
FLUSH BINARY LOGS是最快解法：它强制滚动日志，触发内核真正释放空间 - 如果无法立刻 flush（比如业务高峰期），可临时加个
SET GLOBAL max_binlog_size = 1024;再等自然 rollover，但不推荐长期设过小值 - 绝对不要杀 mysqld 进程来“释放句柄”，这会导致事务中断和数据不一致
最易被忽略的一点：PURGE 不是“删文件”动作，而是“标记+清理索引+通知释放”的组合操作；只要跳过 SHOW SLAVE STATUS 校验、或误删了 Relay_Master_Log_File 对应的文件，主从就会卡在 Got fatal error 1236，修复成本远高于提前多看一眼从库状态。
