mysql如何使用锁监控器Innodb_lock_monitor输出详细锁状态到日志

innodb_lock_monitor是mysql innodb存储引擎自带的锁监控组件，开启后会定期将引擎层面的锁状态、活跃事务信息、锁等待链路等内容输出到mysql的错误日志中，是排查锁冲突、死锁等问题的常用工具。

开启Innodb_lock_monitor的前置条件

首先需要确认当前mysql版本是否支持该监控器，innodb_lock_monitor从mysql 5.6版本开始正式提供，所有使用该版本及更高版本的innodb引擎实例都可以正常开启。同时要确保mysql的错误日志路径配置正确，且有写入权限，否则监控内容无法正常输出。

开启Innodb_lock_monitor的具体步骤

方法一：通过SQL语句临时开启

这种方式不需要重启mysql实例，修改会在实例重启后失效，适合临时排查问题使用。只需要执行以下SQL语句即可：

-- 开启Innodb_lock_monitor，本质是创建一个名为innodb_lock_monitor的临时表
CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;

执行成功后，innodb引擎会自动识别该表的存在，启动锁监控逻辑，默认每15秒向错误日志输出一次锁状态信息。

方法二：通过配置文件永久开启

如果需要长期开启锁监控，可以修改mysql的配置文件my.cnf（linux系统）或my.ini（windows系统），在[mysqld]配置段下添加以下内容：

[mysqld]
# 开启innodb锁监控器
innodb_monitor_enable=innodb_lock_monitor

修改完成后重启mysql实例，监控器会自动生效，重启后配置依然保留。

查看输出的锁状态日志

开启监控器后，锁状态信息会输出到mysql的错误日志文件中，错误日志的默认路径可以通过以下SQL查询：

SHOW VARIABLES LIKE 'log_error';

打开对应的错误日志文件，就可以看到类似以下的锁状态输出内容：

===============================
2024-05-20 10:30:00 0x7f8a1c0b3700 INNODB MONITOR OUTPUT
===============================
Per second averages calculated from the last 15 seconds
------------------------
LATEST DETECTED DEADLOCK
------------------------
2024-05-20 10:28:12 0x7f8a1c0b3700
*** (1) TRANSACTION:
TRANSACTION 421342, ACTIVE 3 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 12, OS thread handle 140248765562624, query id 345 localhost root updating
UPDATE user SET age=20 WHERE id=1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 3 n bits 72 index PRIMARY of table `test`.`user` trx id 421342 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION 421343, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 13, OS thread handle 140248765563648, query id 346 localhost root updating
UPDATE user SET age=21 WHERE id=1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 58 page no 3 n bits 72 index PRIMARY of table `test`.`user` trx id 421343 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 3 n bits 72 index PRIMARY of table `test`.`user` trx id 421343 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
Trx id counter 421344
Purge done for trx's n:o < 421340 undo n:o < 0 state: running but idle
History list length 12
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421341, not started
MySQL thread id 11, OS thread handle 140248765561600, query id 344 localhost root
---TRANSACTION 421340, not started
MySQL thread id 10, OS thread handle 140248765560576, query id 343 localhost root
--------
FILE I/O
--------
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
 ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 0; buffer pool: 0
143 OS file reads, 67 OS file writes, 34 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 2 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 23456789
Log flushed up to   23456789
Pages flushed up to 23456789
Last checkpoint at  23456789
0 pending log flushes, 0 pending chkp writes
34 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 102400
Buffer pool size   8192
Free buffers       7000
Database pages     1192
Old database pages 0
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1192, created 0, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 1192, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=1234, Main thread ID=140248765564672, state: sleeping
Number of rows inserted 0, updated 2, deleted 0, read 10
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
===============================

日志内容关键部分解读

输出的日志包含多个模块，排查锁问题时重点关注以下几个部分：

• LATEST DETECTED DEADLOCK：记录最近一次发生的死锁详情，包括涉及的事务ID、执行的SQL语句、持有的锁和等待的锁信息，以及最终回滚的事务。
• TRANSACTIONS：记录当前所有活跃事务的状态，包括事务ID、活跃时长、锁结构数量、执行的SQL内容等。
• RECORD LOCKS：具体的行锁信息，会标注锁所在的表、索引、锁模式（比如X锁、S锁）、是否是间隙锁等。

关闭Innodb_lock_monitor的方法

临时开启的关闭方式

如果是通过创建表的方式临时开启的，直接删除该表即可关闭监控：

DROP TABLE innodb_lock_monitor;

配置文件开启的关闭方式

如果是通过配置文件永久开启的，需要删除my.cnf或my.ini中[mysqld]段的innodb_monitor_enable=innodb_lock_monitor配置，然后重启mysql实例即可。

使用注意事项

虽然innodb_lock_monitor输出的信息很详细，但使用时需要注意以下几点：

• 开启监控后，错误日志会快速增长，尤其是业务高峰期锁操作频繁时，日志体积会明显增大，建议只在排查问题时开启，问题解决后及时关闭。
• 该监控器输出的信息是周期性的，默认15秒输出一次，无法实时捕获所有锁操作，只能看到周期内的锁状态快照。
• 如果只需要查看死锁信息，可以开启innodb_print_all_deadlocks参数，该参数只会将死锁信息输出到错误日志，不会输出完整的锁状态，日志量更小。
• mysql 8.0版本后，官方更推荐使用performance_schema中的锁相关表来查询锁信息，比如data_locks、data_lock_waits表，查询更灵活，不需要输出日志。

mysqlInnodb_lock_monitor锁监控锁状态日志修改时间：2026-06-25 09:00:50