必须先确认中继日志使用状态再清理：通过SHOW SLAVE STATUS查看Relay_Log_File和Exec_Master_Log_Pos，仅删除已执行完毕的旧文件；复制异常时禁止清理；推荐用RESET SLAVE安全释放空间。
从库磁盘爆满，先别删文件！确认中继日志是否还在用
直接 rm -f 中继日志（relay-log.*）是高危操作——MySQL 从库可能正往里写，删了会导致复制中断、数据不一致，甚至启动失败。必须先看状态，再动手。
-
SHOW SLAVE STATUS\G查关键字段：Relay_Log_File（当前正在写的中继日志名）、Relay_Master_Log_File（对应主库 binlog 文件）、Exec_Master_Log_Pos（已执行到的位置） - 所有
relay-log.*文件中，只有Relay_Log_File及其之后的几个（通常 1–2 个）是活跃的；更早的、且Exec_Master_Log_Pos已越过的，才可清理 - 如果
Seconds_Behind_Master非零或为NULL，说明复制延迟或异常，此时禁止任何日志清理操作
安全清理中继日志：用 RESET SLAVE 还是 RESET SLAVE ALL？
RESET SLAVE 会清空中继日志文件、重置复制坐标（Relay_Log_File/Relay_Log_Pos），但保留 MASTER_HOST 等连接信息；RESET SLAVE ALL 还会清除这些配置，需重新 CHANGE MASTER TO。
- 仅释放空间、复制正常：用
RESET SLAVE即可。执行后 MySQL 自动删除旧中继日志，并新建relay-log.000001 - 你不确定复制是否健康，或想彻底重建复制链路：用
RESET SLAVE ALL，但务必提前记下SHOW SLAVE STATUS中的Master_Host、Master_Port、Master_User、Master_Log_File和Master_Log_Pos - ⚠️ 注意：
RESET SLAVE不影响主库 binlog，也不触发主从重连，它只是“清空从库本地缓存”——所以执行后要手动START SLAVE
为什么 FLUSH LOGS 对中继日志无效？
FLUSH LOGS 只对错误日志、慢查询日志、二进制日志生效，它会让 MySQL 关闭并重新打开这些日志文件，从而轮转出新文件。但中继日志由复制线程自主管理，不受该命令控制。
- 试图用
FLUSH LOGS“刷新”中继日志，不会产生新文件，也不会清理旧文件 - 有些文档误传“先
STOP SLAVE再FLUSH LOGS就能清理”，这是错的——FLUSH LOGS根本不碰 relay-log - 真正有效的清理动作只有两个：
RESET SLAVE（推荐） 或 手动rm+FLUSH RELAY LOGS（不推荐，风险高）
自动防复发：禁用中继日志自动轮转？不，该配的是 relay_log_purge
MySQL 默认开启 relay_log_purge = ON，表示“中继日志在 SQL 线程执行完后自动删除”。如果它被关了，旧中继日志就会堆积——这才是很多从库磁盘满的真正原因。
- 检查当前值：
SHOW VARIABLES LIKE 'relay_log_purge';，输出应为ON - 若为
OFF，立即修复：SET GLOBAL relay_log_purge = ON;（重启后失效）；永久生效需在my.cnf的[mysqld]段添加：relay_log_purge = ON - 注意：
relay_log_purge和expire_logs_days无关，后者只管 binlog；中继日志的自动清理完全依赖前者
最常被忽略的一点：清理完中继日志后，df -h 可能仍显示空间未释放——因为文件被进程占用，rm 后空间未立即归还。此时只需重启 MySQL（或至少 STOP SLAVE; START SLAVE;），让复制线程重新加载，内核才会真正回收磁盘块。
