mysql如何查看当前锁等待情况_分析information_schema锁表

MySQL锁等待排查：从瞬时快照到完整现场

数据库性能突然下降，事务长时间无响应？这通常是锁等待问题导致的。但锁究竟在哪里，谁在等待谁，如何快速精准定位？不必慌张，掌握一套从快照分析到上下文还原的组合排查方法，能帮助你迅速找到问题根源。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

排查锁等待最快的方法是查询INNODB_LOCK_WAITS表，返回空结果表示当前没有活跃的锁等待；若结果非空，则通过requesting_trx_id和blocking_trx_id关联INNODB_TRX表定位阻塞事务及其SQL语句，MySQL 8.0及以上版本推荐使用performance_schema.data_lock_waits进行更细粒度的分析。

排查锁等待：直接查询 INNODB_LOCK_WAITS 最快捷

遇到事务卡顿，第一步无需急于翻查日志，直接切入核心即可。INNODB_LOCK_WAITS 这张系统表正是为此场景设计——它专门记录“谁在等待、被谁阻塞”的瞬时关系，结构简洁明了，查询结果一目了然。

• 执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;。若查询结果为空，则表明当前时刻不存在活跃的锁等待（请注意，这并不意味着“没有锁”，仅代表“没有发生阻塞”）。
• 一旦返回非空结果，关键信息便已呈现：立即关注 requesting_trx_id（等待事务ID）和 blocking_trx_id（阻塞事务ID）这两个核心字段。它们是后续深入排查的线索。
• 这里存在一个重要特性：INNODB_LOCK_WAITS 本质上是内存中的快照信息，锁一旦被释放，相关记录便会立即消失。因此，排查动作务必迅速，最好在系统卡顿发生的当下立即执行查询，否则等你着手处理时，可能已经“案发现场”空空如也。

定位阻塞源头：通过 trx_mysql_thread_id 找到问题SQL

仅知道事务ID在阻塞还不够，必须查明它具体在执行什么操作。是忘记提交的长事务，还是自身也被阻塞的“链式阻塞”？

• 使用上一步获取的 blocking_trx_id，查询 INNODB_TRX 表：SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_id = 'xxx';
• trx_state 是核心判断依据。若状态为 RUNNING 且 trx_started 是数分钟甚至更早之前，基本可判定是长事务在作祟。若状态为 LOCK WAIT，则情况更复杂——说明这个“阻塞者”自身也在等待，典型的链式阻塞已经形成。
• trx_mysql_thread_id 可直接用于执行 KILL 命令终止会话。虽然它通常与 SHOW PROCESSLIST 中的 ID 一致，但为确保准确，建议优先以此字段为准。
• 权限问题不容忽视：普通用户默认无法查看其他用户的 INNODB_TRX 信息，这可能导致误判为“无锁”。因此，提前为相关监控或运维账号授予 PROCESS 权限，是数据库管理的常规操作。

MySQL 8.0+ 版本推荐使用 performance_schema.data_lock_waits

对于MySQL 8.0及更高版本，排查方式有所升级。旧的 INNODB_LOCKS 表已被移除，取而代之的是 performance_schema 下的新表。data_lock_waits 不仅字段定义更清晰，还能直接关联到具体的表名和行锁对象，实现更细粒度的排查。

• 查询锁等待关系可以使用如下语句： SELECT r.OBJECT_NAME, r.LOCK_MODE AS requested_mode, b.LOCK_MODE AS blocking_mode, r.OWNER_THREAD_ID, b.OWNER_THREAD_ID FROM performance_schema.data_lock_waits w JOIN performance_schema.data_locks r ON w.REQUESTING_ENGINE_LOCK_ID = r.ENGINE_LOCK_ID JOIN performance_schema.data_locks b ON w.BLOCKING_ENGINE_LOCK_ID = b.ENGINE_LOCK_ID;
• 新方案支持按数据库进行过滤，例如添加 WHERE r.OBJECT_SCHEMA = 'your_db' 条件，能有效避免被其他无关数据库的锁信息干扰，提升排查效率。
• 这套方案对数据库性能影响较小，但前提是确认 performance_schema 功能已启用，并且 data_locks 和 data_lock_waits 这两个 consumers 处于开启状态（通常默认是开启的）。

辅助验证：使用 SHOW ENGINE INNODB STATUS\G 查看完整上下文

当锁等待链条复杂，或需要确认是否刚刚发生过死锁时，这个命令就派上用场了。它不提供结构化的表格输出，但能还原最完整的现场信息，是深度分析的利器。

• 重点关注命令输出中的 TRANSACTIONS 部分。这里会详细列出每条事务“正在等待哪个锁”（waiting for this lock）以及“持有哪些锁”（holds the following locks），信息具体到索引、数据页和记录级别。
• LATEST DETECTED DEADLOCK 区域是分析死锁的权威来源。它会完整记录两个冲突事务的SQL语句、各自持有的锁以及等待的锁，是复盘死锁成因、进行SQL优化的唯一可靠依据。
• 这里同样存在时效性问题：SHOW ENGINE INNODB STATUS 的输出信息来自循环缓冲区，仅保留最近一次死锁和部分事务快照。若未能及时查看，关键信息便会丢失。因此，建议在系统出现卡顿的当下立即执行该命令并保存输出结果，切勿等待“稍后处理”。

归根结底，锁问题最棘手的部分，往往并非技术层面的“无法查询”，而是业务层面的“不敢操作”。真正拖垮数据库性能的，可能就是一个忘记 COMMIT 的连接，或者一条未使用索引的 UPDATE 语句。这些导致性能问题的细节，就隐藏在 trx_query 的SQL文本和 trx_started 的时间戳里。它们不在系统视图的结构中，而在你愿意深入分析的那几行输出信息里。