性能测试与 MySQL 调优是“问题定位→数据验证→针对性优化→效果复测”闭环，需关注 P90/P95/P99 响应时间分布、TPS/QPS 线性度、Threads_created/Connections 等状态比值、慢日志与 EXPLAIN 分析，并交叉验证 I /O、内存、CPU 等系统指标。
性能测试 结果分析和 MySQL 调优不是孤立步骤，而是“问题定位 → 数据验证 → 针对性优化 → 效果复测”的闭环。关键不在于看单个指标高低，而在于识别瓶颈是否真实、是否可归因、是否可干预。
重点关注响应时间与吞吐量的分布特征
平均响应时间（Avg RT）容易掩盖长尾问题。必须查看 P90、P95、P99 响应时间，以及响应时间直方图或箱线图。若 P99 远高于 Avg（例如 Avg 50ms，P99 达 800ms），说明少量慢查询拖累整体体验，此时应优先抓取慢日志中执行时间 > 200ms 的 SQL；同时比对吞吐量（TPS/QPS）是否随并发增长而线性上升——若并发从 100 增至 200，TPS 只提升 10%，大概率存在锁竞争或资源争用。
结合 MySQL 状态变量定位典型瓶颈类型
通过 SHOW GLOBAL STATUS 或 performance_schema 实时采集关键指标，聚焦以下几组比值：
- Threads_created / Connections > 0.1：说明连接复用不足，频繁创建线程，需检查应用连接池配置（如 maxActive、minIdle）或启用 thread_cache_size
- Handler_read_rnd_next / Handler_read_next > 0.1：反映大量回表或全表扫描，提示索引覆盖不足，应检查执行计划中 type=ALL/INDEX、Extra 含 Using filesort/Using temporary
- Innodb_row_lock_waits 持续增长：表明写冲突严重，需排查 热点 更新（如计数器字段）、事务粒度是否过大、是否缺少合适索引导致锁范围扩大
- Key_reads / Key_read_requests > 0.01：MyISAM 缓存命中率低（若仍在用 MyISAM）；但更常见的是误读——InnoDB 不走 key_buffer，此项仅作排除参考
慢查询日志 + 执行计划是调优的黄金组合
开启 slow_query_log（long_query_time ≤ 1s），配合 log_queries_not_using_indexes；对高频慢 SQL，用 EXPLAIN FORMAT=JSON 分析执行路径。重点看：
- 是否使用了预期索引（key 字段）；若为 NULL，检查索引列顺序、隐式类型转换、函数包裹字段（如 WHERE YEAR(create_time)=2024）
- rows 值是否远大于实际返回行数（说明索引选择性差或统计信息过期），可运行 ANALYZE TABLE 更新
- Extra 中出现 Using index condition 表示用了 ICP（索引条件下推），是好事；出现 Using where; Using index 表示覆盖索引，理想状态；出现 Using temporary/Using filesort 则需优化排序逻辑或加联合索引
区分数据库层瓶颈与外部干扰
MySQL 自身负载未必是根因。需交叉验证：
