查不到目标连接id是因权限不足，非命令失效；执行show processlist返回空或仅自身连接，说明缺少process权限；需用root授grant process on . to 'u'@'h'; flush privileges;或改查performance_schema.threads。
查不到目标连接 ID 是权限不足，不是命令没生效
执行 SHOW PROCESSLIST 返回空或只看到自己的连接，大概率是当前账号没被授予 PROCESS 权限。MySQL 默认限制用户只能看自己发起的连接，这是安全机制，不是 bug。
确认方式：先执行 SELECT CURRENT_USER();，再查 SELECT * FROM information_schema.PROCESSLIST; —— 若报错 Access denied for SELECT on information_schema.PROCESSLIST，就坐实了权限问题。
解决路径只有两条：
- 用
root或已授PROCESS权限的账号重连（如GRANT PROCESS ON *.* TO 'monitor'@'%'; FLUSH PRIVILEGES;） - 若无法切换账号，可尝试从 Performance Schema 绕行（需
SELECT权限）：SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO IS NOT NULL AND PROCESSLIST_TIME > 60;
KILL QUERY id 比 KILL id 更安全，尤其对连接池场景
权限异常常伴随慢查询卡在某个语句上（比如没加索引的 SELECT、锁表的 UPDATE），此时直接 KILL id 会断开整个 TCP 连接，连接池可能误判为网络故障，触发重建连接、重试逻辑甚至雪崩。
更稳妥的做法是只中断语句本身，让连接继续存活：
-
KILL QUERY 12345：仅终止该连接当前正在跑的 SQL，状态变为Query→Killed，后续还能复用 -
KILL 12345：干掉整个连接，状态变Connect→NULL，客户端收到Lost connection错误 - 权限异常下，若连接已卡在
Waiting for table metadata lock，KILL QUERY无效，必须用KILL CONNECTION 12345（KILL的完整写法）
STATE 为 Killed 不代表已结束，大事务回滚会拖慢实际释放
执行 KILL QUERY 或 KILL CONNECTION 后，SHOW PROCESSLIST 中对应连接的 State 立刻变成 Killed，但这只是 MySQL 接收到了指令。真正释放资源要等它做完清理工作。
关键点：
- 如果被杀查询已修改大量数据但未提交，MySQL 必须回滚——这个过程不可中断，耗时取决于已写多少 undo log
- 可通过
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_ROWS_MODIFIED FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = 12345;查是否还在回滚中 - 别反复
KILL，重复发令无意义；等待期间连接仍占着线程和内存
权限异常慢查询背后，往往藏着未提交事务或 DDL 阻塞
单纯“慢”不一定是 SQL 写得差，更可能是权限异常导致客户端行为失常：比如应用捕获到 Access denied 却没正确关闭连接，或因权限不足跳过事务提交逻辑，留下一个挂着的事务锁住表。
排查时别只盯 Time 列，重点看：
-
State = Waiting for table metadata lock：说明有 DDL（如ALTER TABLE）被阻塞，源头通常是未提交的事务——查INNODB_TRX找TRX_STARTED最早的那个 -
Command = Sleep但Time > 300且Info为空：极可能是客户端崩溃后连接没释放，属于僵死会话，该用KILL CONNECTION -
Host字段显示内网 IP 但User是app_user，却执行着SELECT * FROM mysql.user：基本可判定是权限配置错误后应用在盲目试探，应立刻干预
真正的难点不在怎么杀，而在杀完之后——那个被中断的事务是否还在锁表？有没有其他连接正等它释放资源？这些不会自动消失，得靠 INNODB_TRX 和 INNODB_LOCK_WAITS 交叉验证。
