17370845950

5分钟内定位数据库锁问题需组合三类命令：先用SHOW OPEN TABLES筛选表级锁，再依MySQL版本查INNODB_TRX与Performance Schema定位行锁等待，最后用SHOW ENGINE INNODB STATUS和SHOW STATUS分析锁统计与死锁。

直接看当前有没有锁、谁在等、谁在占——用这三类命令组合，5分钟内定位问题。

查哪些表正被锁住（最快速初筛）

执行 SHOW OPEN TABLES WHERE In_use > 0，它只反映 MyISAM 表或显式 LOCK TABLES 引起的表级锁定，对 InnoDB 的行锁不敏感。但胜在快、无权限依赖、一眼看出“哪个表卡住了”。

• 如果返回空，说明没有表级锁（但不代表没行锁）
• In_use 值大于 0：该表正被某个事务/线程打开并使用中（常见于长事务未提交）
• Name_locked 为 YES：表名被锁定，通常发生在 DROP TABLE 或 RENAME TABLE 过程中

查正在运行的事务和锁等待关系（InnoDB 核心诊断）

这是排查 InnoDB 行锁问题的核心路径。注意 MySQL 版本差异极大：

• MySQL 5.7 及更早：
  

  SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

  
  

  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

  
  

  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

• MySQL 8.0+：
  INNODB_LOCKS 和 INNODB_LOCK_WAITS 已废弃，改用 Performance Schema：
  

  SELECT * FROM performance_schema.data_locks;

  
  

  SELECT * FROM performance_schema.data_lock_waits;

• INNODB_TRX 在所有版本都可用，重点关注字段：
   • trx_state = 'LOCK WAIT' → 正在等锁
   • trx_mysql_thread_id → 对应 SHOW PROCESSLIST 中的 ID，可用来 KILL
   • trx_query → 当前执行的 SQL（可能被截断，用 SHOW FULL PROCESSLIST 补全）

查锁统计与死锁现场（辅助判断严重性）

这类命令不显示具体锁对象，但能告诉你“锁是不是频繁发生”或“最近有没有死锁”：

• SHOW ENGINE INNODB STATUS\G —— 必跑命令。
   • 看 TRANSACTIONS 部分：当前活跃事务 + 每个事务持有的锁（包括锁类型、记录、索引）
   • 看 LATEST DETECTED DEADLOCK：最近一次死锁的完整上下文（谁持有什么锁、谁在等什么、最终哪个事务被回滚）
• SHOW STATUS LIKE 'innodb_row_lock_%'; —— 看趋势：
   • innodb_row_lock_current_waits > 0？说明此刻就有事务在等行锁
   • innodb_row_lock_time_avg 突然飙升？大概率有慢查询或未提交事务拖累
• SHOW STATUS LIKE '%lock%'; —— 区分表锁 vs 行锁压力：
   • table_locks_waited 高 → MyISAM 表或显式锁表操作多
   • innodb_row_lock_waits（旧版）或 data_lock_waits（8.0+）高 → 行锁竞争激烈

容易被忽略的关键点

很多同学查完 INNODB_TRX 发现一堆 LOCK WAIT 就慌了，其实真正要盯的是：
• trx_started 时间——如果等锁超过 30 秒，大概率是上游应用没处理好异常或超时；
• trx_weight（事务权重）大的事务，往往持有多个锁、回滚代价高，别急着 KILL；
• performance_schema.data_locks 默认可能关闭，需确认：SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/lock%';，状态为 ENABLED 才能查到锁详情。