查不到 data_lock_waits 通常是因为锁采集器未启用，需按顺序开启 wait/lock、transaction instruments 和 global/thread/data_locks consumers，并在阻塞发生瞬间抓取快照；metadata_locks 中 GRANTED 的 SHARED_READ 锁才是 DDL 卡死主因。
查不到 data_lock_waits？先确认锁采集器开了没
MySQL 8.0 默认关闭所有锁相关 instrument，data_lock_waits 为空几乎肯定是采集链断了，不是没锁。必须手动启用三类配置，且顺序不能错：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'wait/lock/%';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'transaction%';UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation', 'data_locks');
执行后立刻验证：SELECT COUNT(*) FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/lock/%' AND ENABLED = 'YES';——结果至少 10+ 行才算生效。只开 consumers 不开 instruments，照样查不到。
data_lock_waits 查不到阻塞？你可能没卡在“正在发生”的瞬间
data_lock_waits 是瞬时快照，不是日志：事务一提交、锁一释放，对应行就消失。它只记录“当前正被阻塞”的状态，不是“曾经被阻塞”。
- 会话 A 执行
BEGIN; SELECT * FROM t WHERE id = 1 FOR UPDATE;后不提交 - 会话 B 执行相同
SELECT ... FOR UPDATE卡住（State 变为Updating或Waiting for table metadata lock） - 此时**立刻**在会话 C 中查
SELECT * FROM performance_schema.data_lock_waits;
错过这个窗口，表就空了。别等业务报警后再查——得在现象复现时同步抓取。
为什么 SHOW PROCESSLIST 看不到阻塞源？因为它是 Sleep 的“静默持有者”
一个未提交的 SELECT 或 BEGIN 后空闲的应用连接，在 PROCESSLIST 里显示为 Sleep，Info 字段为空，但仍在持有 MDL_SHARED_READ 锁。这种连接根本不会出现在活跃 SQL 监控里，却能卡死 ALTER TABLE。
- 查
performance_schema.metadata_locks才能暴露它：SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, OWNER_THREAD_ID FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'PENDING' OR LOCK_TYPE = 'EXCLUSIVE'; - 用
OWNER_THREAD_ID关联performance_schema.threads，看PROCESSLIST_INFO是否为空、THREAD_OS_ID是否异常驻留 - 再结合
INFORMATION_SCHEMA.INNODB_TRX确认trx_state = 'RUNNING'但trx_query IS NULL——这就是悬挂事务
别只盯着行锁，metadata_locks 才是线上 DDL 卡死的主因
DDL 操作（如 ALTER TABLE）需要 MDL_EXCLUSIVE 锁，而它和任何已存在的 MDL 锁互斥。一个简单的 SELECT 就能持锁数小时，但 data_locks 里完全不体现——它只管 InnoDB 行锁，不管元数据锁。
-
LOCK_TYPE = 'EXCLUSIVE'表示该线程正在执行 DDL 或已获取排他锁 -
LOCK_STATUS = 'PENDING'表示它正在等锁，大概率就是被卡住的ALTER - 真正阻塞它的源头，往往出现在另一条
LOCK_TYPE = 'SHARED_READ'且LOCK_STATUS = 'GRANTED'的记录里——那就是那个“什么都没干却卡死一切”的 Sleep 连接
锁排查最易忽略的点：你查 data_lock_waits 为空，不代表没锁；你看到 SHOW PROCESSLIST 全是 Sleep，也不代表系统空闲。真正的阻塞源，常藏在 metadata_locks 的 GRANTED 状态里，且不带任何 SQL 文本。
