MySQL 性能压测工具深度实践：从部署到多环境对比的完整指南

核心问题：如何系统化地完成 MySQL 性能基准测试，并生成可用于横向对比的生产级性能报告？

在日常数据库运维与架构选型中，性能测试往往停留在零散的手动操作层面。执行几次 sysbench 命令、看一眼 QPS 数值、凭经验判断”够用”，这种模式无法支撑关键业务决策。本文介绍的这套基于 sysbench 与 tsar 的自动化压测方案，正是为了填补这一空白——它不仅实现了测试流程的标准化，更重要的是将性能数据与系统监控精准关联，让每一次测试都可复现、可对比、可量化。通过这套工具链，你将能够在相同基准下对比不同硬件配置、不同 MySQL 参数、不同云厂商实例的真实性能表现，为数据库选型与优化提供坚实的数据支撑。

一、工具的核心定位：它解决了什么痛点？

核心问题：这套工具与手动执行 sysbench 有何本质区别？

手动执行 sysbench 测试存在三个致命缺陷：数据准备不统一、监控采集不精确、结果整理碎片化。本工具通过三层设计彻底解决了这些问题。

1.1 完整的测试场景覆盖

工具预设了四种生产环境最具代表性的负载模型，而非简单的读写混合。每种场景对应真实的业务压力：

点查询（oltp_point_select）：模拟高频缓存命中场景，如用户会话查询、商品信息检索。这类查询侧重考验 InnoDB 缓冲池效率与 CPU 吞吐。
只读事务（oltp_read_only）：模拟复杂报表、数据分析场景，包含范围查询与聚合操作。它会压测排序缓冲区与临时表性能。
读写混合（oltp_read_write）：最接近真实业务，模拟订单处理、用户行为日志写入。该场景下日志刷盘策略与锁竞争成为瓶颈关键。
只写事务（oltp_write_only）：模拟批量数据导入、日志归档等高写入场景，直接暴露磁盘 I/O 子系统与 redo log 配置短板。

应用场景示例：某电商平台在”双十一”前需要评估新采购的 NVMe SSD 服务器是否能承担订单峰值的写入压力。通过单独执行 oltp_write_only 场景，并对比旧 SATA SSD 服务器的测试报告，发现新硬件在 128 线程下 TPS 提升 3.2 倍，但 IO 利用率仅 52%，说明仍有 40% 以上的性能余量，从而放心将核心交易库迁移。

1.2 精准的时间维度监控匹配

传统做法是在测试前后手动执行 iostat 或 top，但采集时间点与压测时段不匹配，导致监控数据失真。本工具强制要求在被压测的 MySQL 宿主机上启动 tsar 监控，并以 1 秒为间隔持续记录。测试脚本会自动提取与压测时段精确对应的监控样本，确保每个 QPS 数据点都有对应的 CPU 与 IO 利用率。

配置要点：启动 tsar 时必须指定数据盘设备名。例如，若 MySQL 数据目录挂载在 /dev/sfdv0n1，命令应为：

nohup tsar --cpu --io -I sfdv0n1 -l -i1 >/tmp/tsar.log &

这里的 -I sfdv0n1 是指定磁盘设备，-i1 是 1 秒采集间隔，-l 是实时输出到日志。若设备名错误，监控数据将为空，生成的报告也会缺失关键 IO 指标。

1.3 自动化报告生成与多环境对比

单次测试生成 HTML 与 Markdown 双格式报告只是基础。真正的价值在于 merge_reports.py 脚本——它可以将不同机房、不同配置、不同云厂商的测试报告整合为统一格式的对比分析文档。例如，你可以清晰看到自建 IDC 的物理机与阿里云 RDS 在相同数据规模下的 QPS 差异、延迟分布与 CPU 消耗，为混合云架构决策提供直接依据。

二、环境准备：每一步都需严谨执行

核心问题：压测环境与生产环境不一致会导致测试结果完全失效，如何确保环境准备的准确性？

性能测试的有效性建立在环境一致性之上。以下准备步骤必须严格执行，任何疏忽都会让测试结果失去参考价值。

2.1 压测客户端配置

压测客户端是发起请求的源头，其自身性能不能成为瓶颈。

操作系统选择：文档明确要求 Linux 环境（CentOS/RHEL/AlmaLinux）。Windows 或 macOS 因网络栈与进程调度差异，无法产生稳定的并发连接。建议压测客户端与 MySQL 服务器位于同一机房内网，网络延迟应低于 1ms。若跨机房测试，需在结果中注明网络损耗。

软件安装：

# CentOS/RHEL 系统
yum install -y sysbench python3

# Ubuntu/Debian 系统  
apt-get install -y sysbench python3

验证安装：

sysbench --version  # 应显示 1.0+
python3 --version   # 应显示 3.6+

作者反思：曾遇到压测客户端因内核参数 net.core.somaxconn 过小，导致高并发下连接队列溢出，测试结果呈现不稳定的断崖式下跌。因此，建议在测试前检查 ulimit -n（文件句柄数）与 net.ipv4.tcp_max_syn_backlog，确保其值大于测试线程数的 2 倍。

2.2 MySQL 服务器端配置

被压测的 MySQL 实例需要调整两个关键点：

安装 tsar 监控工具：

yum install -y tsar

若官方源无 tsar，需从源码编译。tsar 是阿里开源的系统监控工具，比 sar 更轻量，输出格式更易解析。

调整 MySQL 参数：

SET GLOBAL max_prepared_stmt_count = 1048576;

此参数默认值通常为 16382，在高并发 sysbench 测试中极易耗尽，导致”Can’t create more than max_prepared_stmt_count statements”错误。设置为 1048576 可确保测试顺利进行。

磁盘设备识别：这是最容易出错的环节。登录 MySQL 服务器执行：

lsblk | grep -E '(nvme|sda|vda|sfd)'  # 根据实际设备名筛选
df -h | grep mysql  # 查看数据目录挂载点

例如，若输出显示 /dev/sfdv0n1 挂载在 /data/mysql，则 tsar 命令必须是 tsar --cpu --io -I sfdv0n1。注意，这里不需要写完整路径，只需设备名。

2.3 权限与网络要求

MySQL 权限：测试账号需要具备创建库、创建表、插入数据的权限。建议在配置文件中使用专用测试账号：

CREATE USER 'sbtest'@'%' IDENTIFIED BY 'complex_password';
GRANT ALL PRIVILEGES ON sbtest.* TO 'sbtest'@'%';

SSH 免密登录：脚本需要通过 SSH 登录 MySQL 宿主机获取 tsar 日志。配置 root 账号的 SSH key 免密登录：

ssh-copy-id root@YOUR_MYSQL_HOST

验证方法：ssh root@YOUR_MYSQL_HOST "hostname" 应能直接执行并返回主机名。

三、配置文件详解：每个参数都影响测试结果

核心问题：配置文件中的参数如何映射到实际的测试行为与数据规模？

benchmark_config.conf 是测试的”蓝图”，参数设置直接决定了测试的严谨性与可比性。

3.1 基础数据库连接配置

MYSQL_HOST=192.168.1.100      # 必须是内网 IP，公网 IP 会引入网络抖动
MYSQL_PORT=3306               # 非默认端口需显式指定
MYSQL_USER=sbtest             # 专用测试账号
MYSQL_PASSWORD=complex_password
MYSQL_DB=sbtest               # 测试库名，建议与用户名一致避免混淆

场景示例：在混合云架构中，你需要对比腾讯云 MySQL 与自建 IDC 的性能。将两个环境的 IP、端口分别配置为 tencent_cloud.conf 与 idc.conf，保持其他参数（表数量、行数、线程数）完全一致，才能得出公允结论。

3.2 测试数据规模定义

TABLES=16                     # 表数量
TABLE_SIZE=10000000           # 单表行数（一千万）

这两个参数决定了数据集的总量与访问分散度。16 张表 × 一千万行 = 1.6 亿条数据，约 40GB 数据量（含索引）。对于 30GB 内存的实例，这能确保部分数据在缓冲池外，产生真实 IO 压力。若数据量过小，测试结果会虚高，无法反映生产环境。

调整策略：

缓冲池 16GB 以下：保持 16 张表 × 1000 万行
缓冲池 32GB-64GB：可增至 32 张表 × 2000 万行
缓冲池 128GB 以上：可增至 64 张表 × 5000 万行

3.3 测试时间与数据准备

TEST_TIME=30                  # 单场景测试时长（秒）
NEED_PREPARE=true             # 是否重新生成测试数据

TEST_TIME：30 秒是平衡测试效率与数据稳定性的经验值。时间过短（如 10 秒）会导致 QPS 波动大；时间过长（如 120 秒）在多次迭代测试中耗时严重。建议在正式基准测试用 30 秒，快速验证用 10 秒。

NEED_PREPARE：首次测试必须设为 true，脚本会调用 sysbench prepare 生成数据。后续测试若数据未变动，设为 false 可节省 20-30 分钟数据加载时间。但需注意，若表结构或数据被篡改，必须重新准备。

3.4 测试场景与并发线程

SCENARIOS="oltp_point_select oltp_read_only oltp_read_write oltp_write_only"
THREADS="1 8 16 32 64 128"

场景选择：不必每次都运行全部四种。例如，只读业务系统可仅测试 oltp_point_select 与 oltp_read_only；日志写入系统重点测试 oltp_write_only。

线程选择：线程数序列应覆盖从低到高的完整梯度。1 线程反映串行处理能力与单请求延迟；8-32 线程反映日常并发；64-128 线程模拟峰值流量。若服务器 CPU 核心数为 8，线程数超过 128 后性能提升有限，反而会增加调度开销。

作者反思：曾因线程数设置跳跃过大（1, 16, 128）误判了性能拐点。实际应在 32 线程时发现 CPU 已饱和，但缺少 64 线程数据，误以为 128 线程会更高。后来补充 8, 16, 32, 64 后才发现性能在 48 线程达到顶峰后下降。因此，线性递增的线程序列至关重要。

四、首次压测完整操作流程

核心问题：从零开始，如何确保第一次压测就能得到有效的、可信的结果？

4.1 启动 tsar 监控

# 确认数据盘设备名
lsblk
# 输出示例：sfdv0n1  259:2    0  3.5T  0 disk /data

# 启动监控（设备名替换为你的实际盘符）
nohup tsar --cpu --io -I sfdv0n1 -l -i1 >/tmp/tsar.log 2>&1 &

# 验证监控运行
ps aux | grep tsar | grep -v grep
tail -5 /tmp/tsar.log

常见错误：若 tail 输出为空，说明 tsar 未正常写入。检查设备名是否正确，或尝试用 tsar --cpu --io -I sfdv0n1 -l -i1 直接在终端运行看是否有输出。

4.2 准备配置文件

创建 benchmark_config.conf：

# 数据库配置
MYSQL_HOST=192.168.1.100
MYSQL_PORT=3306
MYSQL_USER=sbtest
MYSQL_PASSWORD=your_secure_password
MYSQL_DB=sbtest

# 测试配置
TABLES=16
TABLE_SIZE=10000000
TEST_TIME=30
NEED_PREPARE=true

# 测试场景
SCENARIOS="oltp_point_select oltp_read_only oltp_read_write oltp_write_only"

# 并发线程
THREADS="1 8 16 32 64 128"

安全提示：配置文件含明文密码，必须设置文件权限 chmod 600 benchmark_config.conf，避免泄露。

4.3 执行测试

# 赋予执行权限
chmod +x mysql_benchmark.sh

# 启动测试（自动生成报告）
./mysql_benchmark.sh benchmark_config.conf

执行过程解析：

脚本读取配置文件，验证 MySQL 连接
若 NEED_PREPARE=true，执行 sysbench prepare，生成 16 张表并插入 1000 万行数据/表
按 SCENARIOS 顺序依次测试，每种场景按 THREADS 列表递增线程数
每个线程数测试时长为 TEST_TIME 秒，结束后自动采集 tsar 日志
所有场景完成后，调用 Python 脚本生成 HTML 与 Markdown 报告

自定义执行：

# 快速测试（10秒/场景）
./mysql_benchmark.sh benchmark_config.conf 10

# 使用已有数据（跳过 prepare）
./mysql_benchmark.sh benchmark_config.conf 30 false

作者反思：第一次在生成环境运行，因未评估磁盘空间导致 prepare 阶段失败。16 张表 × 1000 万行写入时，磁盘占用达到 85% 触发告警。建议测试前预留至少 50GB 空闲空间，并监控 df -h 实时变化。若空间不足，可临时将 TABLE_SIZE 调整为 5000000。

五、测试报告深度解读：不止于 QPS

核心问题：自动生成的报告包含哪些关键信息？如何从这些数据中提取可行动的性能洞察？

测试完成后，会在 mysql_benchmark_YYYYMMDD_HHMMSS/ 目录生成两个文件：

5.1 报告结构概览

以默认配置为例，报告包含：

场景	线程数	QPS/TPS	95%延迟 (ms)	CPU%	IO%	监控样本数
oltp_point_select	1	17,109	0.06	1.2%	0.1%	30
oltp_point_select	128	321,410	0.41	12.9%	0.1%	30
oltp_write_only	1	12,740	0.08	0.8%	2.1%	30
oltp_write_only	128	139,564	1.83	6.4%	52.3%	30

监控样本数：30 表示 30 秒测试期采集了 30 个 tsar 样本（每秒一个），与 TEST_TIME 完全对应。若样本数少于预期，说明 tsar 采集丢失，需检查监控稳定性。

5.2 关键指标解读

QPS vs TPS：

oltp_point_select 与 oltp_read_only 主要关注 QPS（每秒查询数）
oltp_read_write 与 oltp_write_only 主要关注 TPS（每秒事务数，一个事务含多个语句）

延迟分布：95% 延迟反映了绝大多数用户的体验。若 95% 延迟超过 10ms，说明系统在高并发下响应恶化，需排查锁等待或 IO 瓶颈。

CPU% 与 IO% 的关联分析：

高 QPS + 低 CPU% + 低 IO%：查询命中缓冲池，CPU 未饱和，有上升空间
高 QPS + 高 CPU% + 低 IO%：CPU 成为瓶颈，需优化查询或升级 CPU
低 QPS + 低 CPU% + 高 IO%：磁盘 IO 瓶颈，需优化索引或升级存储
低 QPS + 高 CPU% + 高 IO%：系统性瓶颈，需综合调优

场景示例：某次测试中，oltp_read_write 场景在 64 线程时 QPS 为 45,000，CPU 利用率 85%，IO 利用率 15%。当线程增至 128 时，QPS 仅微增至 46,500，CPU 达到 98%，IO 仍为 15%。结论：该配置下，性能瓶颈在 CPU，增加线程无益，应优化查询复杂度或升级 CPU 主频。

5.3 报告文件内容

performance_report.html：可视化图表，适合向管理层展示。包含 QPS/TPS 折线图、延迟柱状图、CPU/IO 利用率趋势图。

performance_report.md：结构化文本，适合技术归档与版本对比。包含详细配置、原始数据表格、环境信息（通过 SHOW VARIABLES 采集的 MySQL 参数）。

tsar.log：原始监控数据，可用于二次分析。格式为时间戳 + CPU% + IO%，例如：

20241130 14:30:01  45.2  12.3
20241130 14:30:02  47.8  13.1

六、多环境性能对比：挖掘数据背后的架构决策价值

核心问题：当拥有多个环境的测试报告后，如何科学地对比并得出可指导架构选型的结论？

6.1 对比的价值与前提

单一环境的测试只能回答”这个配置性能如何”，无法回答”A 配置比 B 配置好多少，好在哪里”。通过 merge_reports.py，可将不同环境的报告合并，生成横向对比。

前提条件：各环境的测试配置必须严格一致——相同的表数量、行数、线程数、测试时长。唯一差异应是待对比的变量（如 CPU 型号、磁盘类型、MySQL 版本）。

6.2 操作步骤

假设已有三个环境的测试报告：

idc/：自建机房，Intel 6248R，SATA SSD
huawei/：华为云，鲲鹏 920，NVMe SSD
aliyun/：阿里云，Intel 8269CY，ESSD

目录结构：

sysbench_report/
├── merge_reports.py
├── idc/
│   └── performance_report.md
├── huawei/
│   └── performance_report.md
└── aliyun/
│   └── performance_report.md

执行合并：

python3 merge_reports.py idc,huawei,aliyun

输出 mysql_sysbench.md，包含：

环境配置对比表：自动提取各环境的 innodb_buffer_pool_size 并转换为 GB，对比 CPU、内存、磁盘类型
性能汇总表：四种场景、所有线程数的 QPS/TPS 并列对比，直接显示百分比差异
延迟分析：95% 延迟的横向比较
关键发现：自动识别性能最高/最低的环境，并给出初步分析

6.3 实际案例解读

某互联网公司需将数据库从自建 IDC 迁移至公有云，通过对比发现：

场景	IDC (QPS)	华为云 (QPS)	阿里云 (QPS)	结论
点查询 (128线程)	280,000	320,000	340,000	阿里云领先 21%
只写 (128线程)	95,000	145,000	138,000	华为云领先 52%
CPU 利用率	95%	78%	82%	华为云 CPU 效率更高

决策洞察：虽然阿里云点查询性能最强，但华为云在写入场景优势明显，且 CPU 利用率更低，意味着在同等负载下资源更充裕。由于业务以订单写入为主，最终选择华为云，并将节省的 CPU 资源用于部署只读副本。

七、常见问题排查与性能调优

核心问题：测试过程中遇到的典型问题有哪些根源？如何系统性调优而非盲目尝试？

7.1 高频问题排查

问题一：连接失败

# 测试连通性
mysql -h MYSQL_HOST -P 3306 -u sbtest -p

# 检查防火墙
telnet MYSQL_HOST 3306

根源：可能是账号权限限制、MySQL bind-address 未开放、安全组/iptables 拦截。

问题二：tsar 监控数据为空

# 在 MySQL 服务器上检查
ps aux | grep tsar
ls -la /tmp/tsar.log
ssh root@MYSQL_HOST "tail /tmp/tsar.log"

根源：99% 是设备名错误。必须确认 tsar -I 后的参数与实际数据盘设备名完全一致。

问题三：max_prepared_stmt_count 耗尽
表现：sysbench 报错 “Can’t create more than max_prepared_stmt_count statements”
解决：在 MySQL 中执行 SET GLOBAL max_prepared_stmt_count = 1048576;，并建议写入 my.cnf 永久生效。

问题四：prepare 阶段磁盘空间不足
表现：sysbench prepare 中途失败，磁盘使用率 100%
解决：清理日志或扩容。预防性检查：df -h 确保空闲空间 > 50GB。

7.2 MySQL 参数调优建议

基于测试反馈的调优方向：

缓冲池大小：若点查询场景 IO% > 10%，说明缓冲池不足

-- 建议设置为物理内存的 70%
SET GLOBAL innodb_buffer_pool_size = '24G';  -- 对于 32GB 内存服务器

日志刷盘策略：若只写场景延迟高，IO 利用率正常，可调整：

-- 性能模式，每秒刷盘，可能丢失 1 秒事务
SET GLOBAL innodb_flush_log_at_trx_commit = 2;

-- 双一模式，每次事务刷盘，最安全但性能最低
SET GLOBAL innodb_flush_log_at_trx_commit = 1;

连接数限制：若测试中报 “Too many connections”

SET GLOBAL max_connections = 500;

作者反思：调优最忌讳”一步到位”。曾将 innodb_buffer_pool_size 从 8G 直接调到 48G（64G 内存），结果导致系统 SWAP 激增，性能反而下降。正确做法是每次调整 20%，观察 10 分钟，确认无 SWAP 且 QPS 提升后再继续。性能调优是渐进过程，数据驱动比经验主义更可靠。

八、实用摘要与操作清单

核心问题：如何快速将本文转化为可执行的行动计划？

8.1 测试前检查清单

[ ] 客户端：已安装 sysbench 1.0+ 与 Python 3.6+
[ ] 服务器：已安装 tsar，并确认数据盘设备名
[ ] MySQL：已创建专用测试账号，授予足够权限
[ ] 参数：已设置 max_prepared_stmt_count = 1048576
[ ] 网络：客户端与服务器内网延迟 < 1ms，SSH 免密登录正常
[ ] 磁盘：服务器空闲空间 > 50GB，df -h 确认
[ ] 配置：benchmark_config.conf 中设备名、IP、密码已修改
[ ] 监控：已启动 tsar 并验证日志有输出

8.2 标准测试流程

准备环境：按清单检查，启动 tsar
编辑配置：复制 benchmark_config.conf 为 mytest.conf，填写真实参数
执行测试：./mysql_benchmark.sh mytest.conf
等待完成：观察日志输出，确保无错误
查看报告：打开 performance_report.html，检查样本数是否完整
保存结果：将报告目录重命名为有意义的名字，如 mysql_benchmark_idc_v1

8.3 多环境对比流程

统一配置：确保各环境的 benchmark_config.conf 中测试参数完全一致
分别测试：在每个环境独立执行测试，生成报告目录
整理目录：将所有报告目录移至同一父目录，确保每个目录下有 performance_report.md
执行合并：python3 merge_reports.py env1,env2,env3
分析结论：阅读生成的 mysql_sysbench.md，识别性能差异与瓶颈

九、一页速览（One-page Summary）

工具定位：基于 sysbench + tsar 的 MySQL 自动化压测与报告生成解决方案。

核心功能：

四种生产级测试场景（点查询、只读、读写、只写）
1 秒级精准系统监控采集
HTML/Markdown 双格式自动报告
多环境性能横向对比

环境要求：

客户端：Linux, sysbench 1.0+, Python 3.6+
服务器：MySQL 5.7/8.0, tsar, SSH root 访问

快速启动三步骤：

# 1. 安装
yum install -y sysbench python3 tsar

# 2. 配置
vi benchmark_config.conf  # 修改 IP、端口、密码、设备名

# 3. 启动监控与测试
ssh root@MYSQL_HOST "tsar --cpu --io -I nvme0n1 -l -i1 >/tmp/tsar.log &"
./mysql_benchmark.sh benchmark_config.conf

关键参数：

TABLES=16, TABLE_SIZE=10000000 → 1.6 亿数据量
TEST_TIME=30 → 每线程数测试 30 秒
THREADS="1 8 16 32 64 128" → 覆盖低至高并发
max_prepared_stmt_count=1048576 → 避免高并发报错

输出：mysql_benchmark_YYYYMMDD_HHMMSS/performance_report.html

多环境对比：python3 merge_reports.py idc,huawei,aliyun

十、常见问题解答 (FAQ)

Q1: 为什么测试前必须启动 tsar？能否用其他监控工具替代？

A: tsar 的 1 秒级采集能与 sysbench 测试时段精确匹配，确保每个性能数据点都有对应的系统负载数据。虽然可用 iostat -x 1 或 vmstat 1 替代，但脚本已集成 tsar 日志解析，替换需修改 Python 报告生成器代码。tsar 轻量、格式规范，是推荐方案。

Q2: 测试数据量如何确定？文档中的 16 张表 × 1000 万行是否固定？

A: 这个规模适用于 16GB-32GB 内存的实例，确保数据量大于缓冲池，产生真实 IO。若服务器内存 64GB，可调整为 32 张表 × 2000 万行；若内存仅 8GB，可减为 8 张表 × 500 万行。原则是 数据总量 = 2-3 倍缓冲池大小。

Q3: 测试时报 “Can’t create more than max_prepared_stmt_count” 错误，如何解决？

A: 这是高并发下 sysbench 预编译语句耗尽。必须在 MySQL 中执行：SET GLOBAL max_prepared_stmt_count = 1048576;。建议同时写入 my.cnf 的 [mysqld] 段：max_prepared_stmt_count = 1048576，避免重启失效。

Q4: 生成的监控样本数少于预期，可能原因是什么？

A: 三种可能：1) tsar 启动时间晚于测试开始时间，提前启动可解决；2) tsar 因设备名错误未写入日志，检查 /tmp/tsar.log 有无数据；3) 测试时长 TEST_TIME 过短，脚本采集频率为 1 秒，若测试 5 秒则样本数为 5。

Q5: 多环境对比时，为何要求测试配置完全相同？

A: 性能对比需控制变量。若表数量、行数、线程数不同，性能差异无法归因于硬件或配置。唯一应变的量是对比目标（如磁盘类型），其他所有参数必须一致，这是科学测试的基本原则。

Q6: 如何判断当前配置是 CPU 瓶颈还是 IO 瓶颈？

A: 查看报告中的 CPU% 与 IO%：若 CPU% > 90% 且 IO% < 30%，为 CPU 瓶颈；若 CPU% < 50% 且 IO% > 80%，为 IO 瓶颈；若两者均高，需综合优化。点查询场景通常为 CPU 瓶颈，只写场景常为 IO 瓶颈。

Q7: 测试过程中能否中断？中断后如何恢复？

A: 可直接 Ctrl+C 中断。若已生成部分数据，下次测试将 NEED_PREPARE=false 即可跳过数据准备阶段，从第一个未完成的场景开始。但建议完整测试以减少数据不一致性。

Q8: 报告中的 95% 延迟与 99% 延迟有何区别？为何重点关注 95%？

A: 95% 延迟表示 95% 的请求在此时间内完成，反映大多数用户体验；99% 延迟反映最差 1% 的请求，受毛刺影响大。文档关注 95% 是因为它更具代表性，能平滑异常值，适合作为 SLA 指标。若 95% 延迟达标而 99% 延迟过高，需排查偶发性锁竞争或刷盘抖动。

MySQL性能压测终极指南：从部署到多环境对比的实战手册