跳转到主内容
新派编程网 - 新潮编程理念，全新技术课堂！
📁 网站地图

mysql如何查看当前锁信息_mysql锁监控方法

林译川
林译川
• 👁 0人浏览过
查锁表用SHOW OPEN TABLES WHERE IN_USE > 0快速定位被占用表；查锁事务用INFORMATION_SCHEMA.INNODB_TRX看持锁线程；查锁等待链用INNODB_LOCK_WAITS定位阻塞关系；辅以SHOW FULL PROCESSLIST验证状态并杀线程。 查锁表：用
SHOW OPEN TABLES
快速定位被占用的表 这个命令最轻量，适合第一眼判断“是不是有表被锁住了”。
IN_USE > 0
表示该表当前正被某个线程使用或锁定（注意：不是所有
IN_USE=1
都代表异常，比如正常读写也会触发，但持续为 1 就值得盯）。
SHOW OPEN TABLES WHERE IN_USE > 0;
—— 只看真正“在用”的表，避免干扰 结果中
Table
列是表名，
Database
列是库名，结合业务快速定位问题模块 ⚠️ 坑：MyISAM 表会显示
IN_USE=1
即使只是简单
SELECT
；InnoDB 表则更依赖事务级锁，这里可能“不显形”，不能只靠它下结论 查锁事务：
INFORMATION_SCHEMA.INNODB_TRX
看谁在持锁 这才是 InnoDB 锁问题的核心入口。它列出所有**正在运行的事务**，包括还没提交、正在等锁、甚至卡住的长事务。
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G
—— 加
\G
让输出更可读，重点关注：
trx_state
（
LOCK WAIT
表示正在等锁）、
trx_started
（判断是否长事务）、
trx_query
（当前执行的 SQL）
trx_mysql_thread_id
是 kill 的关键 ID，不是
PROCESSLIST
里的
ID
，但两者通常一致 ⚠️ 坑：普通用户默认查不到其他用户的事务，需被授予
PROCESS
权限；若没权限，
SHOW PROCESSLIST
只能看到自己线程，容易误判“没锁” 查锁等待链：
INNODB_LOCK_WAITS
找出谁堵了谁 当出现明显阻塞（比如某条 UPDATE 卡住几十秒），这个视图能直接告诉你“谁在等、等谁、被谁拦着”。 MySQL（Linux） MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。 下载
SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, r.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread, b.trx_query AS blocking_query FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS w INNER JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.blocking_trx_id INNER JOIN INFORMATION_SCHEMA.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;
结果里
waiting_query
和
blocking_query
对比一看就明白冲突点在哪（比如一个在更新
user
表主键，另一个在更新同一行的
status
字段） ⚠️ 坑：
INNODB_LOCK_WAITS
是瞬时快照，如果锁已释放，它就为空——所以得在卡顿发生时立刻查，别等“稍后再看” 查进程状态：
SHOW PROCESSLIST
辅助验证和杀线程 它不直接显示锁，但能告诉你线程在干什么、卡在哪一步，是配合前面几个视图做闭环判断的最后一步。
SHOW FULL PROCESSLIST;
—— 加
FULL
才能看到完整 SQL（否则可能被截断） 关注
State
列：
Updating
、
Locked
、
Sending data
、
Waiting for table metadata lock
都可能是锁相关信号 杀线程用
KILL thread_id
;，注意：只能杀自己线程（除非有
SUPER
权限）；杀错可能中断业务事务，先确认
trx_query
再动手 真实场景里，锁问题往往不是单点故障，而是“长事务 + 无索引查询 + 高频轮询”叠加出来的。比如前端每秒调一个没加索引的
SELECT COUNT(*) FROM order WHERE status=1 AND create_time > 'xxx'
，它会扫全表、持 MDL 锁、拖慢后续 DML——这种问题光看
INNODB_TRX
可能只看到“等待”，得结合
PROCESSLIST
的
State
和慢日志才能揪出根因。

相关文章