QPS与Latency图表不能直接对应，因QPS统计所有语句（含心跳包），而Latency仅采样真实执行SQL的线程且排除Sleep状态，二者时间窗口、粒度及过滤逻辑均不一致。
为什么PMM的QPS和Latency图表不能直接对应上
因为QPS（mysql_global_status_questions）统计的是所有语句请求，包括SELECT、INSERT、SET甚至空心跳包；而Latency（如mysql_info_schema_processlist_time或mysqld_exporter采集的mysql_global_status_commands_total按命令类型聚合的延迟）通常只对实际执行SQL的线程采样，且默认排除Sleep状态。两者时间窗口、采样粒度、过滤逻辑都不一致，强行拉到同一坐标轴看“峰值对齐”会误导判断。
实操建议：
- 在Grafana中切换到
PMM > MySQL Overview仪表盘，优先查看 Query Analytics 面板下的Top Queries by Average Latency和Top Queries by Executions，它们基于performance_schema.events_statements_summary_by_digest，语义更准确 - 确认
mysqld_exporter是否启用--collect.global-status和--collect.info-schema.processlist，否则processlist_time指标可能为空或失真 - 若发现QPS突增但Latency无变化，大概率是大量轻量语句（如
SELECT 1健康检查）或连接复用未触发真实查询
如何用PMM的Query Analytics识别真实慢查询瓶颈
PMM的Query Analytics不是简单罗列慢日志，而是把performance_schema的语句摘要（digest）、执行计划、资源消耗（I/O、CPU、Lock time）全链路关联。关键在于别只盯着“平均延迟”，要交叉验证三组数据：
-
avg_timer_wait高 +rows_examined高 → 全表扫描或索引失效，查EXPLAIN FORMAT=TREE确认访问路径 -
lock_time高 +rows_affected低 → 行锁/间隙锁争用，结合PMM > InnoDB Lock Waits面板看阻塞链 -
io_read_bytes或io_write_bytes异常高 → 即使avg_timer_wait不高，也可能压垮磁盘I/O，此时看sys.io_global_by_file_by_bytes定位热点文件（如ibdata1或大表.ibd）
注意：Query Analytics默认只保留最近24小时的摘要，默认采样率100%，但若performance_schema.setup_consumers中events_statements_history_long被禁用，历史SQL文本将不可查——需提前执行：UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'events_statements_history_long';
QPS骤降但Latency没升高？先查连接和缓冲池状态
这种反直觉现象往往意味着数据库“还没来得及处理请求就卡在入口”。PMM里要立刻打开三个面板：
-
PMM > MySQL Connections：看Threads_connected是否逼近max_connections，同时Threads_created是否持续飙升（说明线程缓存失效，频繁创建销毁线程） -
PMM > InnoDB Buffer Pool：检查Innodb_buffer_pool_hit_ratio是否跌破95%，再看Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值——如果后者激增，说明物理读暴涨，QPS自然被I/O拖死 -
PMM > MySQL Replication（即使单机也建议开）：确认Seconds_Behind_Master是否非零，某些复制线程卡住会间接阻塞DML事务提交，表现为QPS下降但单条语句不慢
一个典型陷阱：innodb_buffer_pool_size配置过小，但PMM仪表盘默认不告警。必须手动添加阈值规则：1 - (rate(mysql_global_status_innodb_buffer_pool_reads[1h]) / rate(mysql_global_status_innodb_buffer_pool_read_requests[1h]))
Latency毛刺无法归因？打开Performance Schema细粒度等待事件
PMM默认聚合的Latency来自performance_schema.events_statements_summary_by_digest，它掩盖了底层等待细节。当看到毫秒级毛刺但Query Analytics里找不到对应语句时，要切到原始事件层：
- 在Grafana中进入
PMM > MySQL Performance Schema→Top Wait Events by Total Time面板，重点关注wait/io/file/innodb/innodb_data_file（磁盘读写）、wait/synch/mutex/innodb/buf_pool_mutex（缓冲池争用）、wait/lock/metadata/sql/mdl（元数据锁） - 若
wait/io/file/innodb/innodb_log_file占比突增，说明redo log刷盘压力大，需检查innodb_io_capacity和sync_binlog配置 - 若
wait/synch/rwlock/innodb/dict_operation_lock高频出现，大概率是并发DDL（如ALTER TABLE）导致字典锁争用，此时SHOW PROCESSLIST里会出现大量Waiting for table metadata lock
真正难排查的瓶颈，往往藏在等待事件的组合里——比如buf_pool_mutex等待 + innodb_data_file等待同时升高，说明缓冲池太小又遇上大查询，必须同步调大innodb_buffer_pool_size并优化SQL。
