MySQL 8.0 默认启用 performance_schema，但关键监控能力（锁、索引、内存等）需手动开启 instruments 和 consumers；必须确认其为 ON、threads 表有数据，并在阻塞发生时新会话中查询。
MySQL 8.0 默认已启用 performance_schema，但绝大多数关键监控能力默认是关的——直接查表为空、查不到锁、看不到索引使用，不是配置错了，而是采集开关没开。
确认 performance_schema 确实已启动
别跳过这步。很多问题源于它根本没初始化成功：
- 执行
SHOW VARIABLES LIKE 'performance_schema';，返回值必须是ON；如果是OFF，说明启动时失败，需检查错误日志 - 执行
SELECT COUNT(*) FROM performance_schema.threads;，结果应 > 0（通常几十到上百行），否则 instrumentation 未加载 - 注意：
performance_schema=ON必须写在my.cnf的[mysqld]段并重启生效，动态 SET 不起作用
开启核心采集器：instruments 和 consumers 缺一不可
只开 performance_schema 就像买了相机但没装镜头——能通电，但拍不出东西。必须手动启用两类组件：
-
setup_instruments控制“采集什么”：比如内存分配、锁等待、InnoDB mutex、索引 I/O 等，默认全为NO -
setup_consumers控制“存到哪张表”：比如是否写入events_statements_history_long或data_lock_waits，默认多数为NO - 典型组合（按需执行，非全部）：
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 'statement/sql/%';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/io/table/%';UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation', 'events_statements_history_long');
为什么刚执行完 SQL 还查不到数据？
这不是延迟问题，而是采集链断裂或查询时机不对：
- 新设置只对**后续新建连接**生效，已有连接不会自动继承，需重连或新开会话再试
- 查
data_lock_waits必须在**阻塞正在发生时**——事务未提交、第二个会话卡住的瞬间，稍晚一秒就查不到 - 查
table_io_waits_summary_by_index_usage需等真实 SQL 执行后触发引擎层 I/O，EXPLAIN 不算、Query Cache 命中不算、预编译未执行也不算 - 某些表（如
memory_summary_by_digest）依赖events_statements_summary_by_digest先有数据，后者又依赖statements类 consumer 开启
最容易被忽略的兼容性细节
版本和字段行为差异会直接导致查询报错或返回空：
-
BLOCKING_ENGINE_LOCK_ID在 MySQL 8.0.29 之前不稳定，若查询data_lock_waits报字段不存在或 NULL，先运行SELECT VERSION(); -
replication_group_members是查 MGR 成员状态的唯一可信源，SHOW STATUS LIKE 'group_replication%'在节点失联后可能不返回任何记录 - InnoDB mutex 相关 instruments（如
wait/synch/mutex/innodb/buf_pool_mutex）默认全禁用，且TIMED = 'YES'必须显式设置才能统计等待时间
真正难的不是命令怎么写，而是每次启用新一类监控（锁、内存、索引、ALTER TABLE 进度）都要重新校验对应的 instruments + consumers 组合，并确认当前连接已继承变更——漏掉任意一环，表就还是空的。
