performance_schema锁指标需手动启用instrument才能采集，data_lock_waits仅记录实时等待对，空结果不等于无锁争用；定位持锁者须关联data_locks、threads、events_statements_current及INNODB_TRX综合分析。
performance_schema 的锁指标不是“开箱即用”的实时仪表盘，而是需要先打开采集开关、再按证据链串联查询的诊断流水线。不启用对应 instrument，data_locks 和 data_lock_waits 就是空表，不是没锁，是根本没记。
查 data_lock_waits 返回空，不代表没锁争用
这是最常被误解的一点：data_lock_waits 只记录“当前正在发生的等待关系”，不是所有锁都会出现在这里。它只存 BLOCKING_TRX_ID 和 REQUESTING_TRX_ID 同时存在且尚未释放的等待对。
- 如果一个事务持锁但没人等它，
data_lock_waits就为空——但data_locks里一定有它的记录 - 如果锁刚释放、等待刚解除，该表可能已清空，但
INFORMATION_SCHEMA.INNODB_TRX仍能查到未提交事务 - 间隙锁（GAP）、Next-Key 锁在冲突未触发前不会生成等待条目，但已真实加锁
- 执行
SELECT * FROM performance_schema.data_lock_waits\G前，务必确认：wait/lock/innodb/innodb_lock_monitor在setup_instruments中为ENABLED
定位持锁者必须连查 data_locks + threads + events_statements_current
单看 data_locks 只知道锁了哪张表、哪个索引、什么模式，但不知道是哪个连接、哪条 SQL 在干这事。THREAD_ID 是内部 ID，不能直接对应到 SHOW PROCESSLIST。
- 先从
data_locks拿出THREAD_ID和LOCK_DATA（对行锁，它可能是主键值；对 GAP 锁，显示supremum pseudo-record） - 用
THREAD_ID关联performance_schema.threads，看PROCESSLIST_ID（即 show processlist 中的 ID）和TYPE（FOREGROUND才是用户连接） - 再用同一个
THREAD_ID查events_statements_current的SQL_TEXT——但注意：如果事务已执行完语句、只在 sleep 状态，这里会是NULL - 此时必须 fallback 到
INFORMATION_SCHEMA.INNODB_TRX查TRX_STARTED和TRX_QUERY，人工比对活跃时间
LOCK_DURATION = 'TRANSACTION' 的 MDL 锁最危险
元数据锁（MDL）在 metadata_locks 表中体现为 LOCK_DURATION 字段。这个值决定了锁生命周期，也是迁移后暴增的根本原因。
-
STATEMENT：语句执行完就释放，安全 -
TRANSACTION：事务提交或回滚才释放——哪怕你只执行了一条SELECT ... FOR UPDATE或隐式开启事务的INSERT，锁就挂住了 - 常见陷阱：
autocommit=0配置下，每个 HTTP 请求都开启长事务；ORM 框架自动 begin 但异常路径未 rollback；连接池复用导致事务状态残留 - 查法：先开采集器
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';，再查SELECT * FROM performance_schema.metadata_locks WHERE LOCK_DURATION = 'TRANSACTION' AND LOCK_STATUS = 'GRANTED';
真正难处理的从来不是“谁卡住了”，而是“为什么它还不结束”——LOCK_DATA 显示的是锁住的值，但你看不到它背后那个忘了 COMMIT 的事务，也看不到驱动层静默开启的隐式事务。这些必须靠 INNODB_TRX 的 TRX_STARTED 时间戳和应用日志交叉验证，不能只信 performance_schema 的某一张表。
