mysql如何查看哪个SQL语句持有锁_关联innodb_locks与processlist

时间：2026-04-29 12:51

MySQL锁排查：如何精准定位“谁持锁”及其SQL语句在排查数据库锁等待问题时，一个常见的困惑是：明明看到了锁，却怎么也找不到是哪个具体的SQL语句持有它。这往往不是查询写错了，而是因为INNODB_LOCKS和PROCESSLIST这两个关键信息表，在设计上就没有直接的关联字段。更棘手的是，不同

MySQL锁排查：如何精准定位“谁持锁”及其SQL语句

在排查数据库锁等待问题时，一个常见的困惑是：明明看到了锁，却怎么也找不到是哪个具体的SQL语句持有它。这往往不是查询写错了，而是因为INNODB_LOCKS和PROCESSLIST这两个关键信息表，在设计上就没有直接的关联字段。更棘手的是，不同MySQL版本的行为差异显著，强行关联很容易导致结果遗漏或错误。

为什么不能直接 JOIN `INNODB_LOCKS` 和 `PROCESSLIST`

问题的根源在于表结构设计。INNODB_LOCKS表记录的是锁的元信息，比如锁类型、模式、对象，但它只包含持有锁的事务ID（LOCK_TRX_ID），没有线程ID。反过来，PROCESSLIST表展示的是所有连接线程的运行时状态，包含线程ID（ID），却没有事务ID。这就好比你有两把钥匙，却找不到能同时打开的两把锁——它们之间缺少一个共用的“钥匙孔”。

此外，还有一个版本演进带来的关键变化：从MySQL 8.0.24开始，INNODB_LOCKS已被官方标记为废弃（deprecated），未来的方向是统一使用performance_schema.data_locks。即使在仍可使用的5.7版本中，它也只反映“当前持有锁的事务”的一个瞬间状态，并不保证实时性，也不会包含那些已经释放但尚未被后台清理的锁残留信息。

信息割裂：INNODB_LOCKS不存储SQL文本，而PROCESSLIST的INFO字段在长事务空闲时可能为空，或被截断。
版本差异：事务ID（TRX_ID）和线程ID（THREAD_ID）的格式在不同版本中不同。5.7中是十进制整数，8.0+则变成了十六进制字符串，关联前必须进行类型转换。

MySQL 5.7 正确关联方式：用 `INNODB_TRX` 当中转表

既然两者无法直连，我们就需要一个“中间人”。在5.7环境中，INNODB_TRX表就是这个完美的桥梁。它同时包含了事务ID（TRX_ID）和对应的MySQL线程ID（TRX_MYSQL_THREAD_ID）。完整的关联路径是：INNODB_LOCKS → INNODB_TRX → PROCESSLIST。

执行前，请确保你的账号拥有PROCESS权限，否则在PROCESSLIST中只能看到自己的连接线程。

SELECT
  pl.ID AS thread_id,
  pl.USER,
  pl.HOST,
  pl.DB,
  pl.COMMAND,
  pl.TIME,
  pl.STATE,
  pl.INFO AS executing_sql,
  trx.TRX_ID,
  trx.TRX_STARTED,
  trx.TRX_STATE,
  trx.TRX_QUERY,
  locks.LOCK_TRX_ID,
  locks.LOCK_MODE,
  locks.LOCK_TYPE,
  locks.LOCK_TABLE,
  locks.LOCK_INDEX
FROM information_schema.INNODB_LOCKS locks
INNER JOIN information_schema.INNODB_TRX trx
  ON locks.LOCK_TRX_ID = trx.TRX_ID
INNER JOIN information_schema.PROCESSLIST pl
  ON trx.TRX_MYSQL_THREAD_ID = pl.ID
ORDER BY trx.TRX_STARTED;

使用这个查询时，有几点需要特别注意：

它只返回当前正持有锁且事务仍活跃的记录。如果事务已经提交，锁随之释放，就不会出现在结果中。
TRX_QUERY字段记录的是事务内最近执行的一条语句，不一定是导致加锁的那条SQL。
当PL.INFO为空而TRX_QUERY有值时，应优先参考后者；如果两者都为空，则表明该事务处于空闲状态（如Sleep），但锁尚未释放。

MySQL 8.0+ 推荐用 `performance_schema` 替代

对于MySQL 8.0+的用户，官方推荐路径已经转向performance_schema。虽然data_locks表同样不直接包含线程信息，但通过与INNODB_TRX和threads表关联，可以获得更全面、更可靠的信息。

以下是推荐的查询组合：

SELECT
  t.PROCESSLIST_ID AS thread_id,
  t.PROCESSLIST_USER AS user,
  t.PROCESSLIST_HOST AS host,
  t.PROCESSLIST_DB AS db,
  t.PROCESSLIST_COMMAND AS command,
  t.PROCESSLIST_TIME AS time,
  t.PROCESSLIST_STATE AS state,
  t.PROCESSLIST_INFO AS executing_sql,
  trx.TRX_ID,
  trx.TRX_STARTED,
  trx.TRX_STATE,
  trx.TRX_QUERY,
  dl.ENGINE_TRANSACTION_ID,
  dl.OBJECT_SCHEMA,
  dl.OBJECT_NAME,
  dl.INDEX_NAME,
  dl.LOCK_TYPE,
  dl.LOCK_MODE,
  dl.LOCK_DATA
FROM performance_schema.data_locks dl
INNER JOIN information_schema.INNODB_TRX trx
  ON dl.ENGINE_TRANSACTION_ID = trx.TRX_ID
INNER JOIN performance_schema.threads t
  ON trx.TRX_MYSQL_THREAD_ID = t.THREAD_ID
WHERE t.PROCESSLIST_ID IS NOT NULL
ORDER BY trx.TRX_STARTED;

字段注意：ENGINE_TRANSACTION_ID是8.0+的新字段，对应TRX_ID，类型为BIGINT UNSIGNED，关联时无需进行十六进制转换。
过滤内部线程：threads表比PROCESSLIST更底层。PROCESSLIST_ID为空的记录通常代表内部后台线程（如purge线程），可以直接过滤掉。
前置检查：如果查询结果为空，先别急着下结论。首先检查performance_schema是否启用（SELECT @@performance_schema;应为1），再确认具体的锁采集器是否打开（SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/lock/innodb%';的ENABLED列需为YES）。

真正卡住时，别只盯“持锁者”，先看“等待者”

很多时候，问题的直接表现是一个会话被“卡住”了。此时，我们的目标往往是找到并终止这个等待锁的会话，而不是去追溯那个可能早已执行完毕的持锁者。这时，直接查询锁等待关系表会更高效。

例如，使用performance_schema.data_lock_waits可以清晰地看到谁在等、等谁：

SELECT
  rpl.PROCESSLIST_ID AS waiting_thread,
  rpl.PROCESSLIST_INFO AS waiting_sql,
  bpl.PROCESSLIST_ID AS blocking_thread,
  bpl.PROCESSLIST_INFO AS blocking_sql,
  dlw.BLOCKING_ENGINE_TRANSACTION_ID,
  dlw.REQUESTING_ENGINE_TRANSACTION_ID
FROM performance_schema.data_lock_waits dlw
INNER JOIN performance_schema.threads rpl
  ON dlw.REQUESTING_ENGINE_TRANSACTION_ID = rpl.THREAD_ID
INNER JOIN performance_schema.threads bpl
  ON dlw.BLOCKING_ENGINE_TRANSACTION_ID = bpl.THREAD_ID
INNER JOIN information_schema.INNODB_TRX rtrx
  ON dlw.REQUESTING_ENGINE_TRANSACTION_ID = rtrx.TRX_ID
INNER JOIN information_schema.INNODB_TRX btrx
  ON dlw.BLOCKING_ENGINE_TRANSACTION_ID = btrx.TRX_ID;

目标明确：查询结果中的waiting_thread通常就是你最终需要KILL的目标会话。需要警惕的是，blocking_thread对应的持锁会话可能已经结束，杀它并无意义。
瞬时性：data_lock_waits只记录“正在发生”的等待关系。一旦等待超时回滚或被手动终止，记录就会消失，因此查询动作要快。
信息互补：如果blocking_sql为NULL，不代表持锁事务没有执行过SQL，很可能它当前处于空闲状态但锁未释放。此时应结合btrx.TRX_QUERY字段（事务最近查询）来综合判断。

在实际排查中，最常踩的坑其实是配置和版本兼容性。在8.0中，开启了performance_schema不等于自动开启了锁信息采集；在5.7中，INNODB_LOCKS查不到记录，也不一定代表没有锁，可能是锁已被释放或采集未触发。因此，在决定KILL之前，务必先确认锁是否真实存在、是否仍在生效，避免误操作。

来源：https://www.php.cn/faq/2388492.html

list

上一篇Navicat能否实现脚本运行失败后自动重试_通过批处理脚本结合命令行控制 下一篇mysql如何实现冷备份_停机状态下拷贝data目录与配置文件

本站内容用于信息整理与展示，如有侵权或内容问题请及时联系处理。

同类最新

继续查看同栏目最近更新的文章。

数据库 · 2026-07-02

Redis 7.0增量AOF重写RDB前导码配置详解

先说一个几乎所有人都踩过的典型误区：很多人把 aof-use-rdb-preamble yes 当作开启“增量重写”的开关。实际上，这个配置只干了一件事——让重写后的 AOF 文件头部带上 RDB 快照。它解决的是加载速度问题，跟“增量重写”本身的概念压根不是一回事。真正的增量重写，依赖的是 Red

数据库 · 2026-07-02

在Python Tornado异步框架中安全执行SQL命令的方法与最佳实践

直接在Tornado里用SQLAlchemy同步执行SQL，结果就是阻塞IOLoop，所谓“异步框架里写同步数据库代码”，等于白搭。安全执行的关键不是“怎么写SQL”，而是“怎么不卡住事件循环”。为什么不能在RequestHandler里直接调用session execute() 因为sessio

数据库 · 2026-07-02

利用SQL触发器实现在INSERT数据时自动同步到审计表

先说结论：可以用触发器把 INSERT 数据同步到审计表，但必须用 AFTER INSERT，并且审计表的字段顺序、类型、字符集得和源表严格一致。否则，轻则写入错位、数据截断，重则直接报错、丢数据。下面把这些坑一个一个掰开说。能，但必须用 AFTER INSERT，且审计表字段顺序、类型、字符集要

数据库 · 2026-07-02

如何用SQL编写按不同工作日统计员工出勤率

在实际业务中，统计不同工作日的出勤率是HR系统里的高频需求。如果直接按日期函数分组，很容易掉进语言环境、索引失效或分母口径的坑里。下面就来拆解具体的实现要点。必须用 CASE WHEN 将日期映射为固定 weekday 标签（如 Mon ）再分组，避免语言环境导致的分组断裂；需过滤 DOW IN

数据库 · 2026-07-02

Spring Boot 3动态拼接SQL为何引发严重安全漏洞

SQL注入漏洞的核心成因，本质上是因为用户输入直接参与了SQL语句的字符串拼接，而未采用参数化绑定机制。在MyBatis中使用${}、QueryWrapper中调用apply()与last()、JPA的@Query注解进行拼接等操作，都会绕过PreparedStatement的安全防护。动态字段必须