KILL命令仅设置中断标记，由线程在安全检查点主动响应；KILL QUERY中断当前语句但保留事务，KILL CONNECTION断开连接并回滚事务；标记为Killed不等于已终止，可能卡在不可中断操作中。
MySQL 中 KILL 命令到底在杀什么
它不直接终止操作系统线程，也不强制结束磁盘 I/O；而是给目标连接线程打一个「中断标记」，让 SQL 执行引擎在**安全检查点**（比如每处理一行、每次锁等待返回、每次语句解析阶段切换）主动查这个标记，再决定是否退出。这意味着：一条正在执行 UPDATE 大表、没到检查点的语句，KILL 后可能卡住几秒甚至几十秒才真正停下。
-
KILL发出后，目标连接状态会立刻变成Killed（查SHOW PROCESSLIST可见），但这只是标记，不是结果 - 对
SLEEP、Waiting for table metadata lock这类等待态，响应极快；对Updating、Sending data这类运行态，延迟取决于引擎内部检查频率 - InnoDB 的 DML 操作中，
KILL通常会在下一次行锁获取或事务日志刷盘前生效，但已修改的行不会回滚——除非整个事务被终止
区分 KILL、KILL QUERY 和 KILL CONNECTION
三者行为差异极大，选错等于白操作：
-
KILL <code>id等价于KILL CONNECTION <code>id：断开连接，回滚当前事务，释放所有锁和资源 -
KILL QUERY <code>id：只中断当前正在执行的语句，保留连接和事务上下文；如果事务之前已有其他语句成功执行，那些变更仍有效，后续还能继续提交 - 误用
KILL QUERY处理死锁或元数据锁等待，可能无效——因为线程根本没在“执行查询”，而是在等锁，此时必须用KILL CONNECTION - MySQL 5.7+ 默认启用
innodb_rollback_on_timeout，但仅影响锁等待超时，不影响KILL行为
为什么 KILL 后连接还在 Command: Killed 状态
这是最常见的困惑点：明明执行了 KILL，SHOW PROCESSLIST 却一直显示 Killed，连接没消失。本质是线程正卡在无法响应中断的位置，比如：
- 正在执行 UDF（用户自定义函数）且该函数未调用 MySQL C API 的中断检测接口
- 在 MyISAM 表上执行
REPAIR TABLE，该操作全程不检查中断标记 - InnoDB 正在做崩溃恢复阶段的 buffer pool 扫描，此过程不可中断
- 线程被 OS 信号阻塞（如 SIGSTOP）、或处于内核态（如大量 page fault 导致调度延迟）
此时只能等它自然完成，或重启 MySQL——没有“强制硬杀”机制。
如何安全地终止慢查询而不引发主从延迟或锁堆积
直接 KILL 主库上的长事务，尤其涉及大事务或 binlog_format=STATEMENT 时，容易导致从库重放失败或锁残留。更稳妥的做法是：
- 先查
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = <code>id，确认事务是否持有锁、是否在更新 - 若事务已写入大量 binlog 且未提交，优先考虑
KILL QUERY并让应用层重试，而非直接KILL CONNECTION - 对复制延迟敏感的环境，避免在主库高峰期间
KILL写事务；可先在从库STOP SLAVE，再处理主库问题，防止从库追不上 - 监控层面建议用
performance_schema.events_statements_current替代PROCESSLIST，它能精确看到语句执行到哪一步，比状态字段更可靠
真正麻烦的从来不是怎么发 KILL，而是你不知道它什么时候起效、在哪一步卡住、以及有没有留下未清理的锁或半提交事务。
