Stop Slave卡在Killing slave状态是因为SQL线程正执行事务（如大事务、持锁操作或死锁重试），需等待其自然结束；典型表现是SHOW PROCESSLIST中State为Waiting for table metadata lock或Updating，且Seconds_Behind_Master持续增大。
Stop Slave卡在Killing slave状态的典型原因
这不是命令失效，而是MySQL在等待SQL线程安全退出。只要SQL thread正在执行一个事务（尤其是大事务、长事务或持有锁的操作），STOP SLAVE就会阻塞，直到该事务自然结束或被强制中断。常见触发场景包括：
— 主库刚执行了UPDATE sbtest SET c='mariadb'这类全表更新，binlog传到从库后SQL thread正在逐行应用
— 从库上人为加了LOCK TABLES app.test READ，而主库恰好写入了该表，SQL thread试图获取元数据锁但被阻塞
— 事务中包含大量DML、DDL或跨库操作，导致执行时间远超预期
— 出现死锁重试（如Last_SQL_Errno: 1213），SQL thread反复回滚重试，STOP SLAVE只能等它完成当前重试周期
如何快速确认卡住根源
别急着KILL或重启，先用两个命令定位真实瓶颈：
— 运行SHOW PROCESSLIST，重点看State列：若出现Waiting for table metadata lock或Updating且Time持续增长，说明SQL thread正卡在锁或DML执行中
— 执行SHOW SLAVE STATUS\G，检查Seconds_Behind_Master是否巨大、Relay_Log_Pos是否长期不动、Last_SQL_Error是否有1213或Deadlock字样
— 若State显示Killing slave但Time不断上升，基本可断定是事务未结束，而非权限或网络问题
安全终止卡住的SQL thread的实操步骤
直接KILL SQL thread的连接ID风险极高，可能破坏复制一致性。推荐按顺序尝试：
— 先查出SQL thread对应的Id：SHOW PROCESSLIST里找User为system user、Command为Connect、State含executing或updating的那条记录
— 若确认该线程正在执行无害的单条语句（如简单INSERT），可KILL <id></id>；但若看到State是Waiting for table metadata lock，必须先在另一会话执行UNLOCK TABLES释放读锁
— 更稳妥的做法是只停SQL thread：STOP SLAVE SQL_THREAD，IO thread继续接收binlog，避免relay log堆积；等SQL thread真正退出后再补STOP SLAVE IO_THREAD
— 极端情况下（如已卡数小时且业务不可等），才考虑RESET SLAVE，但它会清空所有复制位点，后续需手动CHANGE MASTER TO重新对齐
为什么KILL进程ID也无效
当STOP SLAVE卡住时，MySQL服务进程本身并未僵死，只是SQL thread在内核态等待事务提交或锁释放。此时KILL <pid></pid>（操作系统级）通常无效，因为MySQL进程仍在响应其他请求；真正要杀的是线程ID（即SHOW PROCESSLIST里的Id），但即使KILL <thread_id></thread_id>也可能被忽略——尤其在线程处于不可中断的内核等待状态（如等待InnoDB buffer pool latch或fsync完成）时。
这种情况下，唯一可靠手段是pkill -9 mysqld，但会导致relay log不完整、GTID gap、甚至需要重建从库。所以日常运维中，宁可等大事务跑完，也不要轻易强杀。
