Performance Schema需手动启用关键采集项，否则events_statements_history_long为空、data_lock_waits查不到实时等待、内存数据为零；MySQL 8.0默认开启但事件全关闭，须显式启用statement/sql/%仪器、events_statements_history_long消费者及锁相关等待仪器，且仅对新连接生效。
Performance Schema 不是开箱即用的“全链路监控”，必须手动启用关键采集项，否则 events_statements_history_long 是空的、data_lock_waits 查不到实时等待、内存分配数据也全为零。
确认并开启 performance_schema 基础采集能力
MySQL 8.0 默认启动 performance_schema，但绝大多数事件默认关闭。只靠 SHOW VARIABLES LIKE 'performance_schema' 返回 ON 并不能说明你在用它。
- 必须显式启用语句级事件采集：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/sql/%'; - 必须启用长历史记录消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history_long'; - 如需锁等待分析，还需开：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME IN ('wait/lock/table/sql/handler', 'wait/lock/metadata/sql/mdl'); - 这些操作仅对新建立的连接生效；已有连接不会自动继承新配置，需重连或重启应用连接池
查正在执行的 SQL 及其完整上下文
光看 events_statements_current 只能拿到线程当前执行的语句（可能已是空闲状态），真正要还原“某次慢查询发生了什么”，得结合历史 + 线程 + 锁三张表关联。
- 先定位可疑线程：
SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO IS NOT NULL AND PROCESSLIST_STATE = 'Executing'; - 再查该线程最近 10 条语句（含参数）：
SELECT SQL_TEXT, TIMER_WAIT, LOCK_TIME FROM performance_schema.events_statements_history_long WHERE THREAD_ID = ? ORDER BY EVENT_ID DESC LIMIT 10; - 若发现某条语句
TIMER_WAIT异常高，立即查它是否在等锁：SELECT * FROM performance_schema.data_lock_waits WHERE OBJECT_SCHEMA = 'your_db' AND THREAD_ID = ?; - 注意：
SQL_TEXT是带真实参数的原始语句，而digest_text在摘要表里已被归一化（如WHERE id = ?），调试时优先看前者
关联锁等待与持有者 SQL 的完整证据链
很多 DBA 卡在“知道有锁等待，但找不到谁在持锁”。关键不是只查 data_lock_waits，而是用它反向关联到持锁线程的当前语句。
- 查等待关系：
SELECT WAITING_THREAD_ID, BLOCKING_THREAD_ID, OBJECT_NAME FROM performance_schema.data_lock_waits; - 通过
BLOCKING_THREAD_ID查持锁线程正在执行什么：SELECT SQL_TEXT FROM performance_schema.events_statements_current WHERE THREAD_ID = ?; - 如果返回空，说明持锁事务已提交或回滚，但锁未及时释放（常见于长事务未提交），此时应查
INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE = 'LOCK WAIT'或TRX_STARTED时间过长的事务 - 切勿依赖
information_schema.INNODB_LOCK_WAITS—— MySQL 8.0 中该表已废弃，字段缺失、数据滞后，无法用于实时排障
避免把 history_long 当成“全量日志”滥用
events_statements_history_long 是环形缓冲区，默认容量 10000 行，高频写入场景下几秒就覆盖。它不是慢日志替代品，而是“故障瞬间快照”工具。
- 默认大小易丢数据：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema_events_statements_history_long_size';，建议压测前调大至 100000 - 它不记录结果集内容、不记录网络传输耗时、不记录客户端断连原因——只记录 server 端语句解析、执行、锁等待等内部阶段耗时
- 若需长期归档或审计，必须配合
slow_query_log（设long_query_time = 0.1）和外部采集（如 pt-query-digest） - 最常被忽略的一点：该表中的
TIMER_WAIT是纳秒单位，直接除以 1000000000 才是秒，不转换会误判为“执行了上亿秒”
