SHOW OPEN TABLES WHERE IN_USE > 0 是最快判断表是否被显式锁定的命令，但它仅反映表级占用（如 LOCK TABLES 或 DDL），无法识别 InnoDB 行锁；真正定位锁类型、持有者及原因需组合查询 INNODB_TRX、data_locks 和 INNODB_LOCK_WAITS。
show open tables where in_use > 0 是最快判断表是否被锁的命令，但它只能告诉你“有锁”，不能告诉你“是什么锁、谁加的、为什么没释放”。真正要定位锁类型和来源，得组合查几个关键视图。
用 show open tables 快速确认表是否被锁
这条命令只对显式加锁（如 LOCK TABLES）或某些 DDL 操作有效，InnoDB 行锁不会触发 in_use > 0。常见误判点：
- MyISAM 表执行
INSERT或UPDATE后，in_use可能为 1；InnoDB 表即使大量行锁堆积，in_use仍为 0 -
Name_locked为 1 表示表名正被重命名或删除操作占用（比如RENAME TABLE），不是数据锁 - 结果为空 ≠ 没锁，只是没触发表级锁定机制
查 information_schema.innodb_trx 找活跃事务
这是诊断 InnoDB 锁问题的第一步，它暴露了“谁在跑、卡在哪、等什么”：
-
trx_state = 'LOCK WAIT'表示该事务正在等锁，记下它的trx_mysql_thread_id -
trx_query显示阻塞语句（注意默认只截取前 100 字符，用show full processlist对照补全） -
trx_started和trx_wait_started能看出锁等待持续了多久，超过 30 秒基本可判定异常 - 如果
trx_state = 'RUNNING'但trx_operation_state是fetching rows或updating or deleting，说明它本身可能持锁未提交
用 performance_schema.data_locks 看锁的具体类型和范围
MySQL 5.7.30+ 默认启用该表，它是目前最准的锁信息源（innodb_locks 在 8.0 已废弃）：
-
LOCK_TYPE值为TABLE→ 表锁；RECORD→ 行锁（含间隙锁）；PAGE极少见，通常表示页级锁退化 -
LOCK_MODE为X或S是常规读写锁，X,GAP或S,GAP表示间隙锁，容易引发死锁但不直接阻塞 SELECT -
LOCK_DATA显示被锁的主键值（如123）或索引字段组合（如3, 'abc'），结合INDEX_NAME能反推出 SQL 是否走了预期索引 - 若看到大量
RECORD锁但LOCK_DATA是空值，大概率是全表扫描触发的隐式锁升级，需检查 WHERE 条件是否命中索引
结合 information_schema.innodb_lock_waits 追踪锁等待链
这张表把“谁等谁”关系扁平化了，适合快速定位根因：
-
blocking_trx_id对应innodb_trx.trx_id，找到持有锁的事务 -
blocking_trx_id和blocking_lock_id联合查data_locks，就能知道它锁了哪条记录、什么模式 - 注意：该表只保留当前等待关系，一旦锁超时或被 Kill，记录就消失，所以必须在等待发生时立刻查
- 如果
blocking_trx_id查不到对应事务，说明那个事务已提交或回滚，但锁还没释放（极少见，多见于崩溃恢复异常）
UPDATE 语句锁了 5000 行，是因为 WHERE 条件没走索引，还是业务确实要批量改？这需要对照执行计划和业务逻辑，不能只看锁本身。 
