该用 KILL QUERY 而不是 KILL CONNECTION 的情况是：连接活跃且仅执行一个慢查询，需终止当前语句但保留连接和事务上下文；KILL CONNECTION 则适用于连接卡在锁等待、Sleep 持有未提交事务等需彻底清理的场景。
什么时候该用 KILL QUERY 而不是 KILL CONNECTION
当一个连接上只跑着一个慢查询（比如 SELECT SLEEP(60) 或大表 JOIN），但连接本身还活跃、没卡死，这时用 KILL QUERY 可以只终止当前正在执行的语句，保留连接和事务上下文。如果事务已经 BEGIN 但还没 COMMIT，KILL QUERY 不会自动回滚整个事务——它只中断当前语句，后续还能继续执行其他语句或手动 ROLLBACK。
常见误判点：看到 State: Sending data 就以为必须杀连接，其实可能只是查询还没返回结果，语句本身仍可控。
-
KILL QUERY发送后，线程状态会短暂变为Killed，然后退出当前语句 - 对已加锁的语句（如
UPDATE ... WHERE卡在行锁上），KILL QUERY会触发锁释放，但释放时机取决于存储引擎（InnoDB 通常较快） - 若语句正在写 binlog 或刷 redo log，
KILL QUERY仍需等待这些原子操作完成，不会立即返回
为什么 KILL CONNECTION 有时比 KILL QUERY 更“干净”
当连接处于 Locked、Waiting for table metadata lock 或长时间 Sleep 且持有未提交事务时，KILL CONNECTION 是更彻底的选择。它直接关闭 TCP 连接，强制 InnoDB 回滚整个事务（包括已执行但未提交的修改），并释放所有锁和内存资源。
注意：KILL CONNECTION 并不等价于客户端断开——MySQL 服务端会主动清理会话状态，而某些客户端（如某些 JDBC 驱动）在连接异常中断后可能残留半开连接，需配合 wait_timeout 和 interactive_timeout 控制。
- 被
KILL CONNECTION的事务，其trx_state在INFORMATION_SCHEMA.INNODB_TRX中会迅速消失 - 若事务已写入部分 redo log，InnoDB 崩溃恢复时能保证原子性，无需人工干预
- 不要对
system_user或复制线程（slave_sql,slave_io）执行KILL CONNECTION，否则可能中断主从同步
如何安全定位并 Kill 长事务，避开误杀
直接查 SHOW PROCESSLIST 容易漏掉“Sleep”但持锁的事务。真正要 Kill 的，是那些 TIME > 60 且 COMMAND = 'Sleep' 但 TRX_STATE = 'RUNNING' 的线程——它们往往卡在应用层没提交。
推荐组合查询：
SELECT p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.STATE, t.TRX_STARTED, t.TRX_STATE, t.TRX_ROWS_MODIFIED FROM information_schema.PROCESSLIST p JOIN information_schema.INNODB_TRX t ON p.ID = t.TRX_MYSQL_THREAD_ID WHERE t.TRX_STARTED < NOW() - INTERVAL 60 SECOND;
- 优先 Kill
TRX_STATE = 'LOCK WAIT'的线程，它们是阻塞源头 - 避免 Kill
USER = 'event_scheduler'或USER = 'root'@'localhost'且HOST匹配运维脚本来源的连接 - 生产环境建议加
--connect-expired-password或限制账号权限，防止低权限用户误 Kill 其他线程
KILL 执行后没反应？可能是这几种情况
执行 KILL QUERY/CONNECTION 后线程仍显示 State: Killed，说明它正处在不可中断点（uninterruptible sleep），比如等待磁盘 IO、持有内核级锁、或在执行 UDF 函数。这不是命令失败，而是 MySQL 正在等安全时机退出。
- InnoDB 在刷脏页（
FLUSH LIST）或做 purge 操作时，KILL 可能延迟数秒到数十秒 - 若线程卡在
Waiting for table flush，通常是其他线程正在执行FLUSH TABLES WITH READ LOCK，需先解除该锁 - 使用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?查看PROCESSLIST_STATE和THREAD_OS_ID，必要时结合系统级工具（如strace -p）确认阻塞点
长事务处理的核心不在 Kill 多快，而在提前识别和约束——比如设置 innodb_lock_wait_timeout、应用层加查询超时、定期扫描 INNODB_TRX 告警，比事后 Kill 更有效。
