直接看当前有没有锁、谁在等、谁在占——用这三类命令组合，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才能查到锁详情。
