Performance Schema 默认启用但关键采集器关闭，需手动开启setup_instruments和setup_consumers才能监控SQL与等待事件；云数据库可能不支持，须验证SHOW ENGINES及表存在性，并注意history表容量限制与性能开销平衡。

Performance Schema 不是“开了就能用”的开关，它默认开着但几乎不采集关键数据——直接查 events_statements_history_long 却返回空，八成是 setup_instruments 和 setup_consumers 还关着。

确认 Performance Schema 真正在工作

只查 SELECT @@performance_schema 返回 1 不够。必须验证三件事：

• 执行 SHOW ENGINES，确认 PERFORMANCE_SCHEMA 行的 Support 值为 YES
• 执行 USE performance_schema; SHOW TABLES LIKE 'events_statements%';，至少看到 events_statements_summary_by_digest 等表存在且可查
• 某些云数据库（如 RDS MySQL 基础版）压根不支持该引擎，SHOW ENGINES 里直接没有这一行

必须手动开启 instruments 和 consumers

MySQL 5.7+ 默认把 SQL 采集器全关了：statement/sql/select、statement/sql/insert 这些默认是 NO；events_statements_history_long 这类消费者也默认禁用。不手动开，等于没装监控。

• 启用语句采集：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%';
• 启用历史和摘要消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history', 'events_statements_history_long', 'events_statements_summary_by_digest');
• 这些修改重启后失效，要永久生效得加到 my.cnf 并配 performance_schema=ON

查慢 SQL 别只盯 slow_query_log

slow_query_log 依赖 long_query_time 阈值，漏掉高频轻量但压垮连接池的语句。真正毛刺在 events_statements_history_long 里，但要注意：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 这个表默认只存 10000 行，按时间倒序覆盖，必须加 ORDER BY SUM_TIMER_WAIT DESC 才能拿到真·耗时大户
• SUM_TIMER_WAIT 单位是皮秒（10⁻¹² 秒），除以 10⁹ 才是秒，别看错数量级
• 查不到 INSERT/UPDATE 却全是 COMMIT？因为事务级事件默认关闭，COMMIT 被单独记一条但本身不耗时，得开 transaction instrument 并查 events_transactions_history_long

从等待事件定位系统级瓶颈

SQL 慢 ≠ SQL 本身有问题。先看全局等待热点：

• 查最耗时的等待类型：SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
• 如果 wait/io/file/innodb/innodb_data_file 排前三，说明 I/O 是瓶颈，再结合 file_summary_by_event_name 看具体哪个文件
• 如果 wait/synch/mutex/innodb/... 或 wait/synch/cond/innodb/... 占比高，大概率是锁或内部同步争用，不是 SQL 改写能解决的
• events_waits_history_long 容量固定，每轮分析后记得 TRUNCATE TABLE performance_schema.events_waits_history_long; 清旧数据，否则新事件进不来

真正容易被忽略的是：history 表大小不调，events_statements_history_long 在高并发下几秒就刷满，查到的全是无效语句；而 setup_instruments 开太多又会拖慢实例——得按需开，比如只开 statement/sql/% 和 wait/io/file/innodb/%，别一上来全开。