relay_log_purge=on默认有效但不足，需人工确认后执行purge relay logs或reset slave；它仅在sql线程执行完且无引用时顺手删单个文件，不按时间清理，高延迟时几乎不生效。
relay_log_purge=ON 是默认且安全的，但仅靠它不够；真正要清理过期 relay-log，得靠人工确认 + PURGE RELAY LOGS 或 RESET SLAVE，不能只等自动机制。
relay_log_purge=ON 到底管不管用
这个参数控制 SQL Thread 执行完一个 relay-log event 后，是否立即尝试删除该文件。设为 ON（MySQL 默认值）时，SQL Thread 每次提交后会检查：当前正在读的 relay-log 是否已全部执行完毕、且没有被 IO Thread 或其他线程引用——满足才删。
但它不看“时间”，也不做批量清理，只在事件粒度上“顺手删”。所以：
- 复制延迟高时，
relay_log_purge几乎不删文件（因为旧文件还在被 SQL Thread 读） - IO Thread 正在写新 relay-log，而 SQL Thread 卡住，老文件就一直挂着
- 哪怕磁盘快满了，它也不会主动触发清理，除非你手动推进复制或重启 SQL Thread
PURGE RELAY LOGS TO 和 BEFORE 命令的实际限制
PURGE RELAY LOGS TO 'relay-log.000012' 看似精准，但风险很高：
- 它按文件名字典序删，不是按内容顺序删——如果 relay-log 文件名被手动改过或有跳号，可能误删正在写的文件
- 命令执行前不会校验
Relay_Log_File是否等于或晚于目标文件名，删完才发现 SQL Thread 还指着relay-log.000011在跑 -
PURGE RELAY LOGS BEFORE '2026-04-10 00:00:00'根本不支持，MySQL 不识别这种语法，会报错ERROR 1064 (42000)
所以这个命令只适合明确知道文件编号边界、且 SHOW SLAVE STATUS 显示 Relay_Log_File 已远超目标编号的场景。
安全清理 relay-log 的三步操作流
别信“自动”二字，每次清理都必须人工介入判断：
- 先执行
SHOW SLAVE STATUS\G，确认Slave_IO_Running: Yes且Slave_SQL_Running: Yes，Seconds_Behind_Master接近 0 - 记下
Relay_Log_File: mysql-relay-bin.000027，说明.000026及更早的文件大概率已执行完（注意：要结合Exec_Master_Log_Pos和Relay_Master_Log_File对比主库 binlog 位置） - 停复制再删：
STOP SLAVE;→PURGE RELAY LOGS TO 'mysql-relay-bin.000027';→START SLAVE;
这一步最关键：STOP SLAVE 能确保 IO Thread 和 SQL Thread 都不再读写 relay-log，避免删到一半被覆盖。
RESET SLAVE vs expire_logs_days 的常见误用
RESET SLAVE 会清空所有 relay-log 并重置复制坐标，但它不是“清理过期日志”的替代方案——它是重置整个从库状态。滥用会导致从库无法继续同步，除非你立刻重新配置 CHANGE MASTER。
另外，expire_logs_days 参数对 relay-log 完全无效（只作用于 binlog），网上很多文档说“设了这个就能自动清 relay-log”是错的。MySQL 官方文档明确说明：relay-log 的生命周期由 relay_log_purge 和复制进度共同决定，和时间无关。
真正容易被忽略的是：当使用 MHA 或类似高可用工具时，它们常把 relay_log_purge=OFF，防止故障切换时丢日志。这种情况下，PURGE RELAY LOGS 就成了唯一可控手段，但必须配合 STOP SLAVE 和状态核对，否则就是给自己埋雷。
