应通过 SHOW SLAVE STATUS\G 查看 Relay_Log_File、Relay_Master_Log_File 和 Exec_Master_Log_Pos，确认已执行完毕的 relay log 才可安全清理；优先使用 PURGE RELAY LOGS TO 命令而非手动删除，启用 relay_log_purge = ON 并配合 relay_log_space_limit 限制磁盘占用。
phpEnv 里的 MySQL 从库 Relay Log 不能直接删文件，必须走 MySQL 内部机制清理，否则复制会中断甚至无法启动。
怎么确认 relay log 还在不在用
登录 phpEnv 自带的 MySQL 客户端（通常是 mysql -uroot -p），执行：
SHOW SLAVE STATUS\G
重点看这三行：
-
Relay_Log_File：IO 线程当前正在写的 relay log 文件名（比如relay-bin.000042） -
Relay_Master_Log_File：SQL 线程已执行到的主库 binlog 名（比如mysql-bin.000038） -
Exec_Master_Log_Pos：对应位置偏移量
所有 relay-bin.* 文件中，只有 Relay_Log_File 及其前 1–2 个（因 rotate 行为可能多留一个）是活跃的；更早的、且 Relay_Master_Log_File 已经越过它的，才可安全清理。如果 Seconds_Behind_Master 是 NULL 或非零，说明复制异常或延迟，此时禁止任何清理操作。
立即学习“PHP免费学习笔记（深入）”；
用 PURGE RELAY LOGS TO 安全删旧文件
这个命令只删指定文件及之前的所有 relay log，MySQL 会校验是否已执行完毕，比手动 rm 安全得多：
PURGE RELAY LOGS TO 'relay-bin.000035';
注意：
- 文件名必须和
SHOW SLAVE STATUS\G中看到的Relay_Log_File格式一致（含前缀、编号、无扩展名） - 不能写成
relay-bin.000035.000001或加.index后缀 - 执行前确保
STOP SLAVE;不是必须的，但若复制卡顿严重，建议先停再清 - 命令成功后，
Relay_Log_Space值应明显下降，可用SHOW SLAVE STATUS\G再次验证
为什么 RESET SLAVE 不推荐日常使用
RESET SLAVE; 会清空所有 relay log + 重置复制坐标（master.info 和 relay-log.info），相当于“重装复制”：
- 它不检查是否已同步完成，直接全部删除，后续
START SLAVE;会从Master_Log_File/Read_Master_Log_Pos继续拉取，风险在于：如果 IO 线程还没写完新日志、或网络抖动，可能丢 event - phpEnv 环境下常用于重配从库，不是空间清理首选
- 执行后需人工确认
Slave_IO_Running和Slave_SQL_Running都为Yes，否则复制没起来
日常磁盘优化，优先用 PURGE RELAY LOGS TO，只删确定已执行完的部分。
让 phpEnv 自动清理 relay log 的配置项
phpEnv 默认不开启 relay log 自动清理，需手动改 MySQL 配置文件（通常在 phpenv/mysql/etc/my.cnf 的 [mysqld] 段）：
- 加一行：
relay_log_purge = ON（重启 MySQL 生效） - 同时建议加：
relay_log_space_limit = 4294967296（4GB 上限，防突发积压） -
expire_logs_days对 relay log 无效，它只管 binlog，别混淆
启用 relay_log_purge = ON 后，SQL 线程每执行完一个 relay log 文件，就立刻 unlink 删除——但前提是该文件确实已全部执行完毕。所以如果复制长期延迟，旧 relay log 仍会堆积，这时得先查 Relay_Master_Log_File 和 Relay_Log_File 差距，而不是只依赖自动清理。
真正容易被忽略的是：relay log 清理时机完全取决于 SQL 线程进度，不是定时任务，也不是按大小触发。哪怕你设了 relay_log_purge = ON，只要复制卡在某个大事务里，对应 relay log 就一直留着不动——这时候光看配置没用，得先解决复制延迟本身。
