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 这类消费者也默认禁用。不手动开，等于没装监控。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 启用语句采集：
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 里，但要注意：
- 这个表默认只存 10000 行，按时间倒序覆盖，必须加
ORDER BY SUM_TIMER_WAIT DESC才能拿到真·耗时大户 -
SUM_TIMER_WAIT单位是皮秒（10⁻¹² 秒），除以 10⁹ 才是秒，别看错数量级 - 查不到 INSERT/UPDATE 却全是 COMMIT？因为事务级事件默认关闭，
COMMIT被单独记一条但本身不耗时，得开transactioninstrument 并查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/%，别一上来全开。
