从实例出发，让你彻底了解InnoDB 锁监控表！

之前的学习中，一出现锁问题，我们都会通过一下两个命令之一来检测事务中的锁问题：

SHOW ENGINE INNODB STATUS;

SHOW FULL PROCESSLIST;

其实，MySQL为我们提供了更好的工具去记录和检测锁问题。大家还记得我们的数据库里有一个 information_schema数据库吗？

该数据库下面有3个重要的表(实际只有一张，其他两张已弃用），分别是：INNODB_TRX、INNODB_LOCKS(已弃用) 和 INNODB_LOCK_WAITS (已弃用) ，用于监控和诊断 InnoDB 引擎中锁与事务状态的系统表，常统称为 InnoDB 锁监控表。它们揭示了事务如何持有或等待锁，是排查锁等待和死锁问题的核心工具。

通过一张表格让大家简要理解一下这三张表：

下面举个例子说明这么查看INNODB_TRX表格：

犯错会吧：

准备两个窗口A、B;

有这么一张dotcpp_user表格：

进入A窗口，此时我们开启事务并对id>2的进行查询并“上锁”：

BEGIN;
SELECT * FROM dotcpp_user WHERE  id>2 FOR UPDATE;

进入B窗口，开启事务并插入一个新用户，（5,'dotcpp_user05','完全二叉树')，此时就等50s吧：

切换information_schema数据库后我们直接开始看表：

先看这张表INNODB_TRX：

mysql> select * from innodb_trx \G
*************************** 1. row ***************************
                    trx_id: 2432
                 trx_state: RUNNING
               trx_started: 2025-09-17 17:36:33
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 2
       trx_mysql_thread_id: 46
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1128
           trx_rows_locked: 3
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL
1 row in set (0.00 sec)

各参数解释如下：

同时，我们通过SHOW FULL PROCESSLIST 语句查看MySQL当前所有的连接状态。该语句通常用来处理突发事件，返回的结果是实时变化的。

mysql> show full processlist;

+----+-----------------+-----------------+--------------------+---------+--------+------------------------+-----------------------+
| Id | User            | Host            | db                 | Command | Time   | State                  | Info                  |
+----+-----------------+-----------------+--------------------+---------+--------+------------------------+-----------------------+
|  5 | event_scheduler | localhost       | NULL               | Daemon  | 176845 | Waiting on empty queue | NULL                  |
| 19 | Dotcpp          | localhost:51732 | dotcpp             | Sleep   |  11769 |                        | NULL                  |
| 43 | Dotcpp          | localhost:54206 | information_schema | Query   |      0 | init                   | show full processlist |
| 46 | Dotcpp          | localhost:55737 | dotcpp             | Sleep   |   1137 |                        | NULL                  |
+----+-----------------+-----------------+--------------------+---------+--------+------------------------+-----------------------+
4 rows in set, 1 warning (0.00 sec)

结合表，我们得知：一个由连接46发起的事务（2432）已经开始了一段时间，它处于“空闲但持有锁”的状态。它自己没有被阻塞，但它手里紧紧抓着3行数据的锁不放，随时可能阻塞其他试图修改这些数据的事务。