性能测试与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 实时采集关键指标，聚焦以下几组比值：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 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 自身负载未必是根因。需交叉验证：
- 对比 iostat -x 1 中 %util 是否持续 > 90%、await 是否突增 → 判断磁盘 I/O 是否饱和（可能由 RAID 配置、SSD 老化或大事务刷脏页引发）
- 用 vmstat 1 观察 si/so（swap 交换）是否非零 → 内存不足触发 swap，InnoDB buffer pool 效能断崖下跌
- 检查 top 中 mysqld CPU 占比，若长期
