查不到PROCESSLIST里的连接ID需用root或具PROCESS权限账号登录，执行SHOW FULL PROCESSLIST查看完整SQL；KILL QUERY id优先于KILL id，避免连接池异常；状态为Killed后延迟终止属正常，需结合INNODB_TRX和sys.session定位卡点。
查不到 PROCESSLIST 里的连接 ID 怎么办
直接连上 MySQL 后，SHOW PROCESSLIST 是唯一能实时看到活跃连接和查询状态的入口。但默认只显示当前用户自己的连接，看不到别人（包括 root）正在跑什么——这是权限限制，不是命令没生效。
- 用
root或有PROCESS权限的账号登录，否则SHOW PROCESSLIST返回结果为空或被截断 - 如果不确定权限，先执行
SELECT CURRENT_USER();确认身份，再查SELECT * FROM information_schema.PROCESSLIST;（需要SELECT权限） - 注意：MySQL 8.0+ 默认隐藏系统线程，加
SHOW FULL PROCESSLIST才能看到完整 SQL 文本，否则可能只显示前 100 字符
KILL 命令到底该杀 ID 还是 QUERY
KILL 有两个变体：KILL [CONNECTION] id 终止整个连接（含后续所有查询），KILL QUERY id 只中断当前正在执行的语句，连接保活。选错会导致业务意外断连。
- 优先用
KILL QUERY <code>id—— 特别是应用用了连接池时，强行KILL <code>id可能让池子误判连接失效，触发重建开销 -
KILL <code>id更适合“卡死连接”场景，比如客户端崩溃但连接没释放，或出现Sleep状态却占着事务锁 - 执行后立刻查
PROCESSLIST，若状态变成Killed，说明命令已接收，但实际终止可能延迟几秒（尤其大事务回滚中）
为什么 KILL 了还一直显示 Query 状态
不是命令失败，而是 MySQL 正在做清理工作：回滚未提交事务、释放锁、刷写日志。这个过程不可中断，耗时取决于被杀查询已执行的操作量。
- UPDATE/DELETE 大表没加 WHERE？回滚可能持续几分钟——因为要重放 undo log 恢复原值
- SELECT 长时间没返回？大概率是等锁（比如被另一个事务锁住某行），
KILL后它会快速退出，不涉及回滚 - 用
INFORMATION_SCHEMA.INNODB_TRX查TRX_STATE和TRX_STARTED，确认是否真在回滚中，而不是卡在 I/O 或网络
MySQL 8.0+ 的替代方案：KILL 不够细？试试 sys.session
原生 PROCESSLIST 字段少、难过滤；sys.session 视图补全了执行时间、内存占用、等待事件等关键维度，更适合定位“慢而顽固”的查询。
- 查运行超 60 秒的非空闲查询：
SELECT conn_id, user, db, command, time, state, current_statement FROM sys.session WHERE time > 60 AND command != 'Sleep'; -
current_statement是截断后的完整 SQL，比PROCESSLIST的INFO列更可靠 - 注意：
sys库默认启用，但部分部署会禁用 performance_schema，导致视图为空——先确认SELECT @@performance_schema;返回ON
真正卡住的从来不是 KILL 命令本身，而是你不知道那个 ID 对应的查询正卡在哪一层：磁盘 I/O、锁等待、还是 giant rollback。多看一眼 INNODB_TRX 和 sys.session，比反复 KILL 有用得多。
