能查也能杀但需分两步:先用information_schema.processlist精准定位慢sql(command='query'且time>60且info非空),再逐个kill对应id;直接批量kill易引发事务中断或锁恶化,且kill不支持where条件。

能查,也能杀,但必须分两步走:先精准定位,再安全终止。直接 KILL 所有 Query 进程极大概率引发事务中断或锁等待恶化。
查正在运行的慢 SQL:用 information_schema.PROCESSLIST 过滤
比 SHOW PROCESSLIST 更可控,支持 WHERE 条件和排序,避免人工扫屏漏判:
-
command = 'Query'排除Sleep连接,只看真正在执行的语句 -
time > 60筛出运行超 60 秒的(按需调低,比如> 10) -
info IS NOT NULL剔除空Info字段(有些线程状态不输出 SQL) - 加
ORDER BY time DESC把最耗时的排在最前面
完整查询示例:
SELECT id, user, host, db, time, state, info FROM information_schema.PROCESSLIST WHERE command = 'Query' AND time > 60 AND info IS NOT NULL ORDER BY time DESC;
KILL 命令只能传整数 ID,不能传条件
MySQL 的 KILL 不接受 WHERE 表达式,必须对每个目标 ID 单独执行。常见误区是写 KILL SELECT id FROM ... —— 这会报语法错误。
- 安全做法:先复制结果里的
id列,逐个执行KILL 12345; - 批量生成命令(仅用于确认后快速执行):
SELECT CONCAT('KILL ', id, ';') FROM information_schema.PROCESSLIST WHERE command = 'Query' AND time > 60 AND info IS NOT NULL;→ 复制输出结果,粘贴到 MySQL 客户端执行(别直接
EXECUTE) - 注意:
KILL是立即生效的强制中断,不会等待事务提交或回滚
哪些 State 值值得优先干预
State 字段比 time 更能反映真实瓶颈,光看耗时可能误判:
-
Locked或Waiting for table metadata lock:大概率是 DDL 操作阻塞了其他查询,优先KILL那个 DDL 线程 -
Copying to tmp table、Sorting result:说明 SQL 缺少合适索引或ORDER BY/GROUP BY数据量过大,杀完要立刻优化 SQL -
Sending data持续几十秒:可能是大结果集网络传输慢,或存储引擎层扫描太重(如 MyISAM 全表锁) -
Updating时间长但没锁:检查是否在更新大量行且没走索引,或触发了复杂触发器
权限和风险必须提前确认
KILL 不是 DBA 专属操作,但普通账号默认无权终止他人线程:
- 执行前确认你有
PROCESS权限(查进程)和SUPER或CONNECTION_ADMIN(杀进程) -
KILL不会自动回滚事务——如果被杀的是一个已修改多行但未COMMIT的事务,这些修改会回滚,但锁释放可能引发下游死锁重试 - 生产环境严禁
KILLId小于 10 的线程(通常是系统内部线程),会导致 MySQL 异常 - 若发现大量慢查询集中爆发,优先查
SHOW ENGINE INNODB STATUS\G是否存在锁竞争,而不是盲目KILL
真正麻烦的从来不是怎么杀,而是杀完之后那个没被优化的 SQL 下一秒又跑起来——查 State、看执行计划、加索引,比敲 KILL 键重要得多。











