STOP SLAVE卡在Killing slave状态说明SQL线程正执行未提交事务，需等待其自然结束才能安全退出；常见于大事务回放、LOCK TABLES未释放、DDL阻塞或死锁重试，此时SHOW PROCESSLIST中State显示Updating、Waiting for table metadata lock或Killing slave且Time持续增长。
STOP SLAVE卡在Killing slave状态说明什么
这表示SQL线程正执行一个未提交的事务，MySQL必须等它自然结束才能安全退出——不是命令失效，也不是进程僵死。常见于大事务回放、LOCK TABLES未释放、DDL阻塞或死锁重试中。此时SHOW PROCESSLIST里能看到State为Updating、Waiting for table metadata lock或Killing slave且Time持续增长。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
为什么直接KILL SQL thread连接ID风险极高
SQL thread的连接ID在SHOW PROCESSLIST中显示为User: system user、Command: Connect，但KILL它可能：
- 导致relay log与binlog位点不一致，后续START SLAVE报错Relay log read failure
- 若事务已写入部分数据但未提交，KILL后InnoDB回滚可能损坏表结构（尤其含DDL时）
- GTID模式下会破坏gtid_executed集合，引发复制断裂
更稳妥的做法是只停SQL线程：STOP SLAVE SQL_THREAD，让IO线程继续接收binlog，避免relay log堆积失控
快速定位并解除阻塞源的实操步骤
别先重启或RESET SLAVE。按顺序执行：
- 查阻塞源头：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
- 找持有锁的会话：SELECT t.PROCESSLIST_ID, t.PROCESSLIST_INFO FROM performance_schema.threads t JOIN performance_schema.metadata_locks ml ON t.THREAD_ID = ml.OWNER_THREAD_ID WHERE ml.OBJECT_SCHEMA = 'your_db' AND ml.OBJECT_NAME = 'your_table';
- 若发现LOCK TABLES ... READ未释放，立刻在另一会话执行UNLOCK TABLES
- 若是长事务阻塞，从information_schema.INNODB_TRX查TRX_STARTED最早的那个，手动COMMIT或ROLLBACK
磁盘满或relay log堆积导致STOP SLAVE无响应怎么办
当OS error code 28: No space left on device出现时，STOP SLAVE可能根本发不出——因为写relay log失败已让SQL线程异常退出。此时：
- 先确认SQL线程是否还在运行：SHOW SLAVE STATUS\G若卡住，说明show slave status本身被global_sid_lock阻塞（MySQL 5.7常见）
- 用pstack 看栈帧，若出现__lll_lock_wait和global_sid_lock->wrlock()，需停掉所有定时执行SHOW MASTER STATUS的监控脚本
- 紧急清理磁盘后，不要直接START SLAVE，先STOP SLAVE SQL_THREAD;再删旧relay log（留Relay_Log_File及更新的），否则可能因索引错位导致复制永久中断
