必须先启用performance_schema.events_waits_current消费者及wait/%类instruments，再查events_waits_current中STATE='WAITING'的记录，通过EVENT_NAME（如wait/lock/metadata/sql/mdl）和TIMER_WAIT定位具体等待类型与耗时。
怎么查 SQL 正在等什么（performance_schema.events_waits_current）
MySQL 8.0 默认不开启等待事件采集，直接查 events_waits_current 可能返回空。必须先确认并启用对应 instrument：
- 检查是否启用：
SELECT * FROM performance_schema.setup_consumers WHERE NAME = 'events_waits_current';—— 若ENABLED是NO，需执行UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_current'; - 同时确保相关 instruments 已开：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/%'; - 查当前线程的等待事件（比如你已知某个慢查询的
THREAD_ID）：SELECT EVENT_NAME, SOURCE, TIMER_WAIT, OBJECT_NAME, INDEX_NAME FROM performance_schema.events_waits_current WHERE THREAD_ID = 123 AND STATE = 'WAITING';
注意：TIMER_WAIT 单位是皮秒（10⁻¹² 秒），数值很大但有意义；EVENT_NAME 为 wait/io/table/sql/handler 表示正在等表 I/O，wait/lock/metadata/sql/mdl 就是元数据锁等待。
怎么定位阻塞源头（data_lock_waits + data_locks 联查）
MySQL 8.0 废弃了 INNODB_LOCKS 和 INNODB_LOCK_WAITS，必须用 performance_schema.data_lock_waits 和 data_locks。关键不是“有没有锁”，而是“谁在等、谁在挡”：
- 先查等待关系：
SELECT * FROM performance_schema.data_lock_waits;—— 关注BLOCKING_ENGINE_LOCK_ID和REQUESTING_ENGINE_LOCK_ID - 再查锁详情：
SELECT ENGINE_LOCK_ID, OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_DATA FROM performance_schema.data_locks WHERE ENGINE_LOCK_ID IN ('xxx', 'yyy'); - 结合
threads表找线程信息：SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE THREAD_ID IN (SELECT OWNER_THREAD_ID FROM performance_schema.data_locks WHERE ENGINE_LOCK_ID IN ('xxx'));
常见陷阱：只查 data_locks 看到一堆锁，但没关联到具体 SQL；必须通过 OWNER_THREAD_ID 回溯到 threads.PROCESSLIST_INFO 才知道那条 SQL 是什么。
为什么 SHOW ENGINE INNODB STATUS 不够用
SHOW ENGINE INNODB STATUS\G 仍可看最近死锁和事务摘要，但它有硬伤：
- 输出是文本块，无法 JOIN 或过滤，不能写成监控脚本
- 只保留最后一次死锁，历史锁等待完全不可追溯
- 事务列表（TRANSACTIONS section）里
trx_mysql_thread_id对应的是连接 ID，但 8.0 的PROCESSLIST表结构变了，ID字段名已改为PROCESSLIST_ID，直接关联容易出错 - 它不展示等待事件层级（比如 MDL → 表 flush → binlog write 这种嵌套等待）
所以日常排查优先走 performance_schema 链路，INNODB STATUS 仅作辅助验证或临时救急。
容易被忽略的权限与初始化步骤
普通账号默认查不了 performance_schema 大部分表，哪怕开了 instruments 也返回空。必须显式授权：
GRANT SELECT ON performance_schema.* TO 'your_user'@'%';- 某些部署（如 Docker 官方镜像）默认禁用
performance_schema，启动时需加参数：--performance-schema=ON -
setup_consumers和setup_instruments的修改是运行时生效，但 MySQL 重启后会恢复默认值，长期监控需写入配置文件或启动脚本固化
最常漏掉的一点：查到 waiting_thread 后，想看它执行了什么 SQL，得去 events_statements_history 查，而不是 PROCESSLIST —— 因为后者只显示当前语句，而历史语句可能才是锁的根源。
