应直接查看query analytics面板而非强行对齐qps与latency图表，因二者采样逻辑、时间窗口及过滤条件不同；qps含健康检查等无效请求，latency仅统计真实sql执行线程。
直接看 Query Analytics，别盯着 QPS 和 Latency 图表对齐
QPS 和 Latency 在 PMM 里天然不匹配，硬拉到同一时间轴对比会误判。QPS（mysql_global_status_questions）包含所有请求，比如 SELECT 1 健康检查、空心跳包；而 Latency 只采样真实执行 SQL 的线程，且默认跳过 Sleep 状态。两者采样逻辑、时间窗口、过滤条件全不同。
实操建议：
- 切到 Grafana 的
PMM > MySQL Overview仪表盘，重点看Query Analytics面板下的Top Queries by Average Latency和Top Queries by Executions - 确认
mysqld_exporter启动时加了--collect.global-status和--collect.info-schema.processlist，否则processlist_time指标可能为空 - 若发现 QPS 突增但 Latency 平稳，优先查连接池行为和健康探针频率，不是数据库真忙了
用 Performance Schema 查慢查询摘要，不是只看慢日志
慢日志只能告诉你“哪条语句慢”，Performance Schema 的 events_statements_summary_by_digest 才能告诉你“哪类语句反复拖垮系统”。它按语句指纹（DIGEST）聚合，屏蔽参数差异，暴露真实瓶颈模式。
实操建议：
- 运行：
SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC LIMIT 10 - 注意
events_statements_history_long默认禁用，历史 SQL 文本查不到——需提前执行：UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'events_statements_history_long' - avg_timer_wait 高 + rows_examined 高 → 很可能是全表扫描，立刻
EXPLAIN FORMAT=TREE看访问路径 - lock_time 高 + rows_affected 低 → 锁争用，配合
PMM > InnoDB Lock Waits面板看谁在等谁
缓冲池命中率骤降？先查 Innodb_buffer_pool_reads 和 Innodb_buffer_pool_read_requests
缓冲池命中率 ≈ 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)。这个比值掉到 95% 以下就得警觉，但别急着调大 innodb_buffer_pool_size——先确认是不是突发大范围扫描或索引失效导致的物理读暴增。
实操建议：
- 查当前值：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%' - 结合
sys.schema_table_statistics或performance_schema.table_io_waits_summary_by_table，看哪些表的io_read_bytes异常高 - 如果
ibdata1或某个大表的.ibd文件 I/O 突增，说明热点数据没被缓存住，而不是缓冲池不够 - 临时表写磁盘多？查
Created_tmp_disk_tables，调大tmp_table_size和max_heap_table_size可能比扩 buffer pool 更有效
Threads_running 持续高于 CPU 核心数？别只 kill 进程
Threads_running 是活跃线程数，不是连接数。它长期超过 CPU 核心数 × 0.8，说明有大量线程在排队等资源——大概率是锁、I/O 或 CPU 密集型查询卡住了。
实操建议：
- 立刻执行：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' ORDER BY TIME DESC LIMIT 10，看哪些线程长时间 RUNNING 或在Locked状态 - 查锁等待：
SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/lock%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5 - 如果是
wait/synch/mutex/innodb/...类等待，说明内部同步争用，可能和并发更新热点行有关 - 别一上来就
KILL，先用pt-kill --busy-time 60 --kill设置阈值自动清理，避免误杀事务中间态
真正难的不是看到指标异常，而是判断哪个指标异常是因、哪个是果。比如 Threads_running 升高，可能是锁导致，也可能是磁盘 I/O 慢拖长了单条 SQL 时间，还可能是应用层重试风暴。必须交叉验证多个维度，不能只盯一个数字。
