reset slave all会彻底清空从库所有复制状态，包括内存中的master_host、master_port等连接参数，导致show slave status无输出；它自动隐式执行stop slave，但建议显式执行以确保安全，且执行后必须用change master to重新配置才能start slave。
会彻底清空从库所有复制状态，包括内存中的连接参数，执行后 SHOW SLAVE STATUS 直接返回空结果。
执行后 SHOW SLAVE STATUS 为什么没输出？
因为 RESET SLAVE ALL 不仅删除磁盘上的 master.info 和 relay-log.info 文件（或对应表 mysql.slave_master_info、mysql.slave_relay_log_info），还会清空 MySQL 实例内存中缓存的主库连接信息：MASTER_HOST、MASTER_PORT、MASTER_USER、MASTER_PASSWORD 等。这些信息一旦消失，SHOW SLAVE STATUS 就找不到任何复制上下文，自然返回空集。
对比 RESET SLAVE：它只删文件/表，不碰内存参数，所以执行后 SHOW SLAVE STATUS 仍显示旧的 Master_Host 等字段（只是 Master_Log_File 和位置全为空）。
执行前必须 STOP SLAVE 吗？
是，但不是“必须先手动执行”——MySQL 5.6.11+ 版本起，RESET SLAVE ALL 会**自动隐式执行 STOP SLAVE**，无需你提前调用。不过仍建议显式执行一次，确认复制线程确实已停：
STOP SLAVE;RESET SLAVE ALL;
这样能避免因线程仍在运行导致的意外行为（比如部分 relay log 被强制截断但未完全清理）。
执行后还能直接 START SLAVE 吗？
不能。因为所有主库连接信息已被清除，此时执行 START SLAVE 会报错：
ERROR 1201 (HY000): Could not initialize master info structure; its record may not exist.
你必须先用 CHANGE MASTER TO 重新指定全部参数，例如：
CHANGE MASTER TO MASTER_HOST = '192.168.1.21', MASTER_PORT = 3306, MASTER_USER = 'repl', MASTER_PASSWORD = 'repl', MASTER_LOG_FILE = 'mysql-bin.000022', MASTER_LOG_POS = 612;
注意：如果原从库启用了 GTID（gtid_mode=ON），则不能带 MASTER_LOG_FILE 和 MASTER_LOG_POS，而应使用 MASTER_AUTO_POSITION = 1，否则会报 ERROR 1776 (HY000)。
容易被忽略的关键点
最常踩的坑是：执行 RESET SLAVE ALL 后忘了重置 MASTER_DELAY 或过滤规则（如 REPLICATE_DO_DB）。这些配置项不会自动恢复，也不会在 CHANGE MASTER TO 中默认继承——你得手动补全，否则可能漏同步、或多同步不该同步的库。
另一个隐形风险：如果从库的 relay_log 文件路径是自定义的（比如通过 relay_log = /data/mysql/relay-bin 配置），RESET SLAVE ALL 会删掉所有现有 relay log，但新生成的第一个 relay log 名称仍按默认规则（如 relay-bin.000001）创建，不一定落在你期望的目录下——务必检查 SHOW VARIABLES LIKE 'relay_log%'; 确认路径是否符合预期。
