必须先确认从库已追上且无延迟，再执行PURGE；否则可能删掉从库正读取的日志导致主从中断。需检查show slave status、GTID同步状态及binlog文件范围，避免误删。
迁移后直接 purge binary logs 很可能删掉正在被从库读取的日志，导致主从中断——必须先确认从库已追上、且无延迟。
确认从库是否还在依赖这些 binlog
迁移完成后，不能假设旧 binlog 全都“无用”。尤其是主从架构未拆干净、或有延迟从库、或使用了 GTID 但未清理 gtid_purged 的情况，PURGE BINARY LOGS 会跳过检查，直接删文件。
- 在主库执行
show slave status\G，检查Relay_Master_Log_File和Exec_Master_Log_Pos，确认所有从库都已执行到当前最新的 binlog 文件和位置 - 如果用了 GTID，运行
select @@global.gtid_executed;，再对比从库的select @@global.gtid_executed;，确保主库没有多出未同步的事务 - 查
show binary logs;看当前最老的 binlog 是哪个；再查show master status;看正在写入的是哪个——中间空档部分才真正“可删”
purge binary logs before 和 to 的行为差异
PURGE BINARY LOGS BEFORE 按时间删，但时间戳是 binlog 文件创建时间（不是事件时间），容易误判；PURGE BINARY LOGS TO 按文件名删，更可控，但必须确保目标文件名是“下一个将被写入”的那个。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00'：删所有创建时间早于该时刻的 binlog 文件。注意：MySQL 5.7+ 中该时间取自文件系统stat时间，非日志内事件时间，迁移后文件时间可能被重置 -
PURGE BINARY LOGS TO 'mysql-bin.000123'：删mysql-bin.000123之前的所有文件（不含该文件）。必须保证mysql-bin.000123是当前show master status显示的File，否则会删掉正在写的日志 - 执行前务必用
show binary logs;核对文件列表，避免因命名不连续（如跳号）导致误删
清理后要立刻检查 index 文件和磁盘空间
PURGE 命令会同时更新 mysql-bin.index，但偶尔因权限或 I/O 问题只删了文件没更新索引，下次 flush logs 可能报错找不到文件。
- 手动检查
cat /data/mysql/mysql-bin.index（路径以实际log_bin_index配置为准），确认内容与show binary logs;输出一致 - 用
ls -lh /data/mysql/mysql-bin.*核对文件是否真被删除；df -h确认磁盘空间释放（注意 ext4 的延迟释放机制，必要时sync） - 如果迁移后启用了新实例但旧 binlog 还挂在原目录，记得检查挂载点和软链，避免
PURGE在错误实例上执行
最容易被忽略的是 GTID 模式下的 gtid_purged 值——它不会随 PURGE 自动更新。删完 binlog 后，如果该值仍包含已删日志的 GTID 范围，新从库初始化时可能拒绝同步。迁移后首次清理，建议执行 RESET MASTER 前先 SET GLOBAL gtid_purged = '';（仅当确定无任何从库依赖旧事务时）。
