performance_schema需手动启用采集器、重连会话并验证初始化：SELECT @@performance_schema为1且threads表行数>0；必须开启对应instruments和consumers；data_lock_waits仅实时记录阻塞瞬态，须在阻塞中查询。
默认已启用，但几乎等于没开——必须手动打开采集器、重连会话、在阻塞发生时查表，否则看到的全是空。
确认 performance_schema 真的启动成功了
很多人卡在这步就停了：SHOW VARIABLES LIKE 'performance_schema'; 返回 ON 不代表它能用。真正要看的是初始化是否完成。
- 执行
SELECT @@performance_schema;，结果为1才算通过 - 立刻查
SELECT COUNT(*) FROM performance_schema.threads;，结果必须 > 0（通常几十行），否则 instrumentation 没加载 - 如果
performance_schema=ON没写在my.cnf的[mysqld]段里，或者没重启 mysqld，动态SET是无效的 - 返回 OFF？别折腾 SQL，直接翻
error.log，常见原因是内存不足或插件冲突
必须开启的 instruments 和 consumers 组合
只开 performance_schema 就像买了显微镜却不装目镜——能通电，但看不到任何东西。锁、内存、索引 I/O 这些关键数据，默认全关。
- 开锁采集（最常漏）：
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_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/sql/%'; - 开消费者（存到哪）：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation', 'events_statements_history_long'); - 执行完立刻验证：
SELECT COUNT(*) FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/lock/%' AND ENABLED = 'YES';至少要返回 10+
为什么刚执行完 SELECT FOR UPDATE 还查不到 data_lock_waits？
performance_schema.data_lock_waits 不是日志表，它只记录“正在发生的阻塞”这一瞬态。事务一提交，行就消失。
- 必须在阻塞“过程中”查：会话 A 执行
BEGIN; SELECT * FROM t WHERE id=1 FOR UPDATE;后不提交；会话 B 执行同样语句卡住；此时立刻在会话 C 中查 - 已有连接不会继承新设置，必须新开会话或重连——老连接查
threads可能都看不到自己的线程 - 只查
TYPE = 'FOREGROUND'的线程，复制线程、后台 purge 线程等不参与锁采集 -
BLOCKING_ENGINE_LOCK_ID在 8.0.29 前不稳定，查出来为 NULL 或报错？先跑SELECT VERSION();
查热点 SQL 不能只看慢查询日志
很多压垮数据库的 SQL 执行时间不到 1 秒，但每秒几百次、扫描上万行、反复分配内存——这些只有 performance_schema 能抓到。
- 查内存大户：
SELECT digest_text AS query, SUM_NUMBER_OF_BYTES_ALLOC FROM performance_schema.memory_summary_by_digest ORDER BY SUM_NUMBER_OF_BYTES_ALLOC DESC LIMIT 10; - 查扫描行数最多：
SELECT digest_text AS query, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_ROWS_EXAMINED DESC LIMIT 10; - 查高频执行：
SELECT digest_text AS query, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC LIMIT 10; -
digest_text是归一化语句（WHERE id = ?），要查真实参数得结合events_statements_history_long - 这些表依赖对应 consumer 开启，且只对新连接生效——别在旧会话里反复刷
最容易被忽略的点：所有采集开关只对新建立的连接生效，而 data_lock_waits 这类表只在阻塞发生的那一秒内有数据。不是配置错了，是时机没卡准。
