直接查INNODB_LOCK_WAITS在MySQL 8.0+中已失效且为瞬时快照，应先用SHOW STATUS LIKE 'innodb_row_lock_current_waits'初筛，再通过INNODB_TRX中trx_state='LOCK WAIT'定位等待事务，最后用performance_schema.data_lock_waits关联INNODB_TRX查阻塞详情。
直接查 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 基本没用——它在 MySQL 8.0+ 中已为空，且在所有版本里都是瞬时快照，稍纵即逝。
先确认当前有没有锁等待（最快初筛）
执行：SHOW STATUS LIKE 'innodb_row_lock_current_waits';。如果返回值大于 0，说明此刻就有事务卡在行锁上，正在等别人释放锁。
- 这个值权限要求低，普通账号也能查，响应快，适合线上快速拍快照
- 它不是累计值，归零不代表问题消失——可能只是锁刚释放、或等待刚好超时（默认
innodb_lock_wait_timeout=50秒） - 搭配看
innodb_row_lock_time_avg：如果平均等待时间突然从0.2ms跳到40ms+，基本可断定有慢事务或未提交事务拖累
查谁在等、谁在挡（MySQL 8.0+ 正确姿势）
MySQL 8.0+ 彻底废弃了 INNODB_LOCK_WAITS 和 INNODB_LOCKS，必须用 performance_schema.data_lock_waits，但默认不采集，得手动开开关。
- 先检查采集是否启用：
SELECT NAME, ENABLED FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/lock/%';，确保wait/lock/innoDB/lock等项为YES - 再打开消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation'); - 然后执行关联查询（注意字段类型匹配）：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_pid, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_pid, b.trx_query blocking_query FROM performance_schema.data_lock_waits w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID JOIN information_schema.INNODB_TRX r ON r.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID;
- 关键点：
BLOCKING_ENGINE_TRANSACTION_ID必须连INNODB_TRX.trx_id，不能误连trx_mysql_thread_id——后者是线程 ID，类型不一致，会查不到结果
为什么你总查不到阻塞链（常见踩坑点）
不是没锁，而是你查的时机或方式错了。
-
INNODB_LOCK_WAITS在 MySQL 8.0+ 中已移除，查它永远返回空；即使在 5.7，它也只保留“正在发生且未超时”的等待，执行SELECT的瞬间锁释放了，就什么也没有 - 只查
data_lock_waits不连INNODB_TRX，只能看到锁 ID，看不到 SQL 和线程，等于只有线索没有嫌疑人 - 没开
performance_schema的锁相关 instruments，data_lock_waits就是空表——这不是 bug，是设计如此 - 普通用户查
INNODB_TRX只能看到自己的事务，需PROCESS权限才能看全；权限不足时，SHOW PROCESSLIST也只会显示自己线程，容易误判“一切正常”
真正可靠的起点永远是 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT'——它不依赖采集开关，不挑版本，只要事务真在等，就一定在这儿露头。其余步骤，都是围绕它展开的验证和溯源。
