跳转到主内容
趣航编程网 - 趣学编程，启航技术之路！
📁 网站地图

mysql如何手动杀死导致锁等待的慢SQL_使用show_processlist与kill命令

顺亿
顺亿
• 👁 0人浏览过
应先用SHOW FULL PROCESSLIST识别真正持有锁的线程，再执行KILL CONNECTION id终止；避免仅按Time排序误杀等待者，需结合State、Command和完整SQL判断阻塞源头。 能直接 kill，但必须先准确识别出真正阻塞别人的那个线程，而不是只看 time 值大的。 单纯按
time
排序杀掉耗时最长的 SQL，经常误杀无辜——它可能只是在等锁，自己没在执行，却把真正持有锁的源头漏掉了。 如何用
show processlist
找到真凶，不是替罪羊 阻塞链里，通常有「等待者」和「持有者」两类线程。只查
show processlist
默认输出，容易只看到一堆
State: Waiting for table metadata lock
或
Waiting for lock
的等待者，却找不到谁在 hold lock。 必须加
FULL
：运行
show full processlist
，否则
Info
列会被截断，看不到完整 SQL，无法判断是否是 DDL、大事务或隐式锁操作 重点看
State
列：出现
Locked
、
Waiting for table metadata lock
、
Waiting for row lock
的线程，大概率是等待者；而
State: Sending data
或
updating
且
Time
持续上涨的，更可能是持有锁正在执行的源头 结合
Command
列：
Command: Query
表示正在执行 SQL；
Command: Sleep
但
Time
很大，说明事务没提交，锁还挂着——这种最危险，常被忽略 别只盯
information_schema.processlist
：它的
TIME
是线程空闲/执行总秒数，不区分状态；而
performance_schema.threads
+
performance_schema.data_locks
（MySQL 8.0+）才能看到谁持有什么锁，但日常应急还是
show full processlist
最快 kill 命令的两种写法，效果完全不同
KILL
不是只有
KILL 123
一种用法。用错类型，可能什么都没终止，或者中断了不该中断的操作。 MySQL（Linux） MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。 下载
KILL 123
（即
KILL CONNECTION 123
）：强制断开客户端连接，会回滚当前事务，释放所有锁。这是最常用、最安全的杀法
KILL QUERY 123
：只终止当前正在执行的语句，但连接保持，事务不回滚。如果该线程处于事务中且已修改数据，
KILL QUERY
后它可能立刻重试原 SQL 或卡在下一行，锁依然存在 不要用
KILL -9
或操作系统级
kill -9
：MySQL 进程本身不能这么杀，会导致实例崩溃或数据不一致 权限要求：执行
KILL
需要有
SUPER
或
CONNECTION_ADMIN
权限（MySQL 8.0.12+），普通应用账号默认没有 批量杀慢查询前，务必加过滤条件 线上环境一执行
SELECT ID FROM information_schema.processlist WHERE TIME > 60
就全量杀，极大概率引发雪崩。慢 ≠ 该杀，更不等于可以一起杀。 加
COMMAND = 'Query'
：排除
Sleep
线程，避免误杀长事务未提交的连接（它们
Time
大但未必在“执行”） 加
INFO IS NOT NULL
：过滤掉空
Info
的线程（比如某些监控探活连接），防止
KILL
报错
Unknown thread id
慎用正则匹配：如
INFO LIKE '%DELETE%'
或
INFO REGEXP '^(INSERT|UPDATE)'
，注意大小写和空格，
SHOW FULL PROCESSLIST
中的 SQL 是原始输入，可能含换行或注释 生产建议：先用
SELECT CONCAT('KILL ',ID,';') FROM ...
生成 kill 语句，人工 review 后再执行；或用
pt-kill
工具替代，它支持
--match-info
和
--ignore-command
等精细控制 真正难的不是执行
KILL
，而是从几十上百个线程里，在 30 秒内分辨出哪个是锁源头、哪个是连锁等待、哪个只是刚连上来还没干活的假慢。多看几遍
show full processlist
输出，比背命令重要得多；而每次
KILL
前确认
State
和
Info
内容，比记住语法关键得多。

相关文章