数据库教程FGMT40‑MySQL性能优化之性能基准测试

数据库教程FGMT40‑MySQL性能优化之性能基准测试

前言与内容大纲

数据库性能基准测试（Benchmark）是DBA开展容量规划、版本选型、参数调优、硬件评估必不可少的技术手段。基准测试区别于业务压力测试，它以标准化负载模型，在可控硬件、操作系统、数据库环境之下，获取数据库系统的吞吐量、响应延迟、并发扩展能力基线数据。MySQL 8.4 LTS与MySQL9.7 LTS作为当前两大长期支持版本，二者在优化器、InnoDB内部逻辑、并发锁机制存在明显差异，风哥教程本文将两套版本各占一半案例，完整讲解基准测试整套理论与大规模实战操作。风哥教程本文面向DBA、运维工程师、数据库开发、云计算工程师，从基准测试理论体系，再到完整的环境部署、工具实操、多场景压测、指标分析、版本对比、压测报告输出，形成一套可以直接在测试环境落地复用的完整流程。

本套风哥教程全部环境硬件规格统一采用64G内存、8CPU服务器；主机分别为fgedu‑net‑cn1作为被测MySQL数据库主机，分别部署MySQL8.4、MySQL9.7两套实例；fgedu‑net‑cn2作为独立压测客户端主机，避免压测工具与数据库抢占CPU、IO资源；文件路径全部统一替换为/fgedudb；实例名、数据库名fgedudb，业务用户名fgedu。风哥教程本文禁止直接在生产环境执行基准压测，所有操作均需要在隔离测试环境完成验证。

风哥教程本文整体知识大纲：

1. MySQL基准测试核心概念与测试目的
2. 基准测试分类：集成基准、组件基准、真实业务负载基准
3. 基准测试核心技术指标：吞吐量、延迟分位数、并发、可扩展性、系统硬件指标
4. MySQL8.4与MySQL9.7版本基准测试关键差异点
5. 主流基准测试工具详解：sysbench、tpcc‑mysql、mysqlslap
6. 基准测试常见误区与风险点
7. 基准测试环境规划，硬件、操作系统、数据库参数配置（64G内存8CPU）
8. 实战一：sysbench完整全流程实战，MySQL8.4环境多场景压测
9. 实战二：sysbench完整全流程实战，MySQL9.7环境多场景压测
10. 实战三：tpcc‑mysql业务模型基准测试，分别在8.4、9.7执行
11. 实战四：mysqlslap快速并发验证测试
12. 实战五：压测数据采集、监控指标采集、结果比对，生成标准化基准测试报告
13. 实战六：基于基准测试结果开展参数调优对比实验
14. 基准测试结果落地，如何把基准数据用于硬件选型、版本升级、容量评估

网上搜索风哥教程可以学习全套数据库教程

一、MySQL性能基准测试理论知识

1.1 基准测试的业务目的

很多技术人员把基准测试简单理解为“把数据库压到最大TPS”，这是片面认知。风哥教程本文明确基准测试核心业务目标，分为五大方向。

第一，硬件评估。当需要采购服务器、存储设备，通过统一基准负载，对比不同CPU型号、SSD存储、内存配置的数据库性能，作为硬件采购的客观依据。64G内存8CPU规格服务器，不同NVMe SSD磁盘，InnoDB读写能力会出现数倍差距，基准测试可以量化硬件差异。

第二，数据库版本选型。本套风哥教程重点对比MySQL8.4 LTS与MySQL9.7 LTS，同一个硬件环境，同一套压测脚本，分别执行压测，对比吞吐量、p95/p99延迟，评估新版本是否适合业务升级，识别新版本潜在性能退化风险。MySQL9.7引入超图优化器，部分复杂JOIN查询性能大幅提升，但少数SQL执行计划反而退化，必须依靠基准测试发现风险。

第三，数据库参数调优对比。修改my.cnf参数前后，运行同一套基准负载，量化参数修改带来性能收益或者性能下降，避免依靠主观感受调整参数。

第四，业务容量规划。通过基准测试得到数据库在指定延迟约束条件下最大可承载TPS/QPS，结合业务未来流量增长，评估数据库实例扩容、分库分表节点规划。业务上线容量不能只看最大TPS，必须绑定延迟指标，例如p99延迟不高于20ms前提下，数据库最大TPS为8500，脱离延迟只谈吞吐量没有业务价值。

第五，故障复现与Bug验证。复现并发锁、高负载下抖动问题，验证数据库Bug修复之后性能是否回归正常。

1.2 基准测试分类

1.2.1 组件基准测试（单组件基准）

仅仅针对MySQL数据库组件开展测试，业务应用层完全剥离。压测客户端直接连接MySQL，使用sysbench、tpcc‑mysql这类工具生成标准化SQL负载，不经过中间业务代码。优点：负载可控、可复现，执行周期短，适合版本对比、参数调优；缺点：负载不完全等价真实业务SQL。本文绝大多数实战属于组件基准测试。

1.2.2 集成基准测试

完整模拟业务全链路，应用服务、中间件、缓存、数据库整套系统一起压测。优点更贴近真实业务；缺点变量太多，数据库性能变化会被应用、网络、缓存干扰，很难定位性能问题到底出在哪一层。

1.2.3 业务真实负载基准

抓取生产环境binlog或者慢查询日志，在测试环境回放真实业务SQL流量。这是最贴近生产真实表现的基准方式，但是流量抓取、回放工具部署复杂；需要注意脱敏，保护业务敏感数据。

风哥 itpux‑com

1.3 基准测试核心指标体系

基准测试不能只看TPS，需要建立完整指标体系，分为数据库业务指标、操作系统硬件指标两大块。

1.3.1 数据库业务指标

1. TPS 每秒事务数（Transactions Per Second）：数据库成功提交事务数量，OLTP业务最重要吞吐量指标。一个事务内部包含多条DML/SELECT语句。
2. QPS 每秒查询数（Queries Per Second）：每秒执行SQL总数量，select、insert、update、delete、commit全部统计在内。
3. 响应延迟Latency：SQL从发起至执行完成返回的耗时。包含平均延迟、最小延迟、最大延迟；最重要的是分位数p50、p95、p99、p999延迟。p99代表99%的SQL请求耗时小于该数值，1%请求耗时高于该数值。线上业务SLO，一般以p95、p99延迟作为约束条件，平均延迟参考价值有限。很多场景平均延迟很低，但是p99延迟很高，业务已经大量超时，平均指标无法体现问题。
4. 并发线程数Threads：压测客户端并发工作线程，不等于数据库连接数。
5. 错误率：压测过程报错事务占总事务比例，高负载下锁等待超时、连接失败都属于错误，错误率高于0代表数据库已经过载。
6. InnoDB内部指标：缓冲池命中率、redo日志等待、锁等待、行锁冲突、脏页刷盘压力。

1.3.2 操作系统硬件指标

1. CPU：user、sys、idle、iowait；数据库理想状态user占比高，iowait低；如果iowait持续很高，代表磁盘IO成为瓶颈。
2. 磁盘IO：iostat观测rMB/s wMB/s，await，svctm，%util；SSD磁盘await应当尽量小于1ms。
3. 内存：空闲内存，swap使用量，一旦swap被使用，MySQL性能会剧烈抖动。
4. 网络：网卡吞吐，网络延迟；压测客户端fgedu‑net‑cn2与数据库主机fgedu‑net‑cn1建议内网万兆网络，避免网络瓶颈干扰数据库压测结果。

1.4 MySQL8.4 LTS 与 MySQL9.7 LTS基准测试关键差异

风哥教程本文实战案例两套版本各占50%，需要理解版本底层差异，才可以读懂两套版本压测结果差异。

MySQL8.4 LTS：稳定长期支持版本，继承8.0架构，InnoDB重做日志使用新参数innodb_redo_log_capacity替代旧版本两个redo文件；默认关闭超图优化器，参数行为和8.0高度兼容，升级风险低，适合存量业务迁移。高并发写入场景存在部分锁竞争，高压力下p99延迟抖动相对明显。

MySQL9.7 LTS：新一代LTS版本，社区版支持Hypergraph超图优化器，复杂多表JOIN查询性能提升明显，但部分简单SQL执行计划可能退化；InnoDB内部锁、latch优化，OLTP读写混合场景同等硬件下吞吐量相比8.4提升20%‑30%，p99延迟抖动更少；提供原子DDL、复制增强等特性；但是新增优化器带来不确定性，上线前必须完整基准测试验证业务SQL集合。

风哥教程 113257174

1.5 主流基准测试工具技术详解

sysbench是本套风哥教程重点实战工具；tpcc‑mysql用来模拟更加真实的电商业务模型；mysqlslap用于快速简易验证，不作为正式深度基准测试工具。

1.6 MySQL基准测试高频误区

风哥教程本文梳理生产环境做基准测试踩坑点，如果规避不当，压测结果完全没有参考价值。

误区1：数据库缓冲池空，没有预热直接开始压测。数据全部在磁盘，压测得到全部是磁盘冷读性能，无法代表业务运行状态。正式压测之前，需要执行一轮预热，把热点数据加载进入innodb buffer pool。

误区2：压测运行时间太短，运行几十秒就停止。压测初期数据库在预热、脏页刷盘，数据波动巨大；正式压测单一场景至少运行300秒，抛弃前30‑60秒预热阶段的数据，取稳定时间段统计结果。

误区3：压测客户端与MySQL部署同一台主机fgedu‑net‑cn1。压测线程抢占CPU内存IO资源，测试结果被压测工具本身干扰。正确做法：压测工具部署独立主机fgedu‑net‑cn2。

误区4：只看TPS，忽略延迟分位数。TPS很高，p99延迟几百毫秒，业务已经大量超时，该TPS业务不可用。基准测试报告必须写明：在p99延迟不超过XX ms约束条件下，最大TPS为XX。

误区5：测试数据集太小，全部数据可以放进文件系统cache，没有真正走到InnoDB磁盘IO。数据集大小需要大于InnoDB缓冲池，模拟真实业务冷热混合数据场景。64G内存机器innodb_buffer_pool_size设置48G，测试数据集需要大于60G。

误区6：多次对比实验环境不一致。修改参数对比，要保证数据集大小、表数量、压测脚本、并发线程、运行时长完全一致，只有待测试变量发生变化。

误区7：开启binlog、redo日志参数随意变动，不同版本对比的时候两套实例参数不一致，版本对比失去意义。做版本对比，my.cnf基础参数必须保持完全相同。

风哥数据库教程 itpux‑com

1.7 基准测试完整标准流程

风哥教程本文定义标准化基准测试流程，所有实战严格按照这套流程执行。

1. 环境准备：确认硬件规格、操作系统版本，部署数据库实例（MySQL8.4或者MySQL9.7），编写my.cnf配置文件；部署压测客户端主机工具。
2. 数据库环境初始化：创建测试库fgedudb，业务账号fgedu。
3. 压测数据prepare阶段：生成测试数据集。数据集大小根据buffer pool规划。
4. 数据库预热阶段：执行一轮查询，将热点数据加载进入InnoDB缓冲池。
5. 监控工具启动：fgedu‑net‑cn1主机开启操作系统指标采集，MySQL性能指标采集。
6. 执行基准run测试；每个并发场景多次重复运行，消除随机误差。
7. 测试结束执行cleanup清理测试数据。
8. 整理采集指标，过滤预热阶段数据，计算TPS/QPS/p50/p95/p99延迟、硬件负载。
9. 记录结果，生成测试报告；更换变量（版本、参数、并发）重复整套流程。

二、基准测试实战环境准备

2.1 硬件与主机说明

• fgedu‑net‑cn1（被测数据库主机）：64G内存，8CPU，NVMe SSD磁盘；操作系统CentOS Stream8；分别部署MySQL8.4实例、MySQL9.7实例，两个实例端口分别33084、33097；数据根路径/fgedudb
• fgedu‑net‑cn2（压测客户端主机）：硬件配置同数据库主机；部署sysbench、tpcc‑mysql、mysqlslap压测工具；万兆内网和fgedu‑net‑cn1互通，不部署MySQL实例。

上51CTO搜索风哥可以学习全套数据库教程

2.2 操作系统层面预配置（两台主机执行）

操作系统内核参数优化，避免压测时文件句柄、连接数限制瓶颈。

#修改文件句柄限制
cat >> /etc/security/limits.conf <<EOF
mysql soft nofile 65535
mysql hard nofile 65535
root soft nofile 65535
root hard nofile 65535
EOF

#内核参数调优
cat >> /etc/sysctl.conf <<EOF
vm.swappiness=1
net.core.somaxconn=4096
net.ipv4.tcp_syncookies = 1
fs.file‑max=655350
EOF
sysctl -p

创建数据库主机fgedu‑net‑cn1目录结构，两套实例数据分别隔离。
MySQL8.4实例目录：

mkdir -p /fgedudb/mysql84/{data,binlog,log,tmp}
chown -R mysql:mysql /fgedudb/mysql84
chmod 700 /fgedudb/mysql84

MySQL9.7实例目录：

mkdir -p /fgedudb/mysql97/{data,binlog,log,tmp}
chown -R mysql:mysql /fgedudb/mysql97
chmod 700 /fgedudb/mysql97

2.3 MySQL8.4 my.cnf配置（64G内存8CPU）

配置文件路径/fgedudb/mysql84/my.cnf

[mysqld]
user=mysql
port=33084
pid‑file=/fgedudb/mysql84/mysql.pid
socket=/fgedudb/mysql84/mysql.sock
datadir=/fgedudb/mysql84/data
basedir=/fgedudb/mysql84
tmpdir=/fgedudb/mysql84/tmp

log_bin=/fgedudb/mysql84/binlog/mysql‑bin
server‑id=1084
binlog_format=ROW
sync_binlog=1
expire_logs_days=7

#64G内存InnoDB核心参数
innodb_buffer_pool_size=48G
innodb_redo_log_capacity=8G
innodb_log_buffer_size=64M
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
innodb_io_capacity=10000
innodb_io_capacity_max=20000
innodb_write_io_threads=16
innodb_read_io_threads=16

max_connections=2000
open_files_limit=65535
table_open_cache=4096
table_definition_cache=2048
character‑set‑server=utf8mb4
collation‑server=utf8mb4_unicode_ci
skip_name_resolve=ON

[mysqld_safe]
log‑error=/fgedudb/mysql84/log/mysqld.err

2.4 MySQL9.7 my.cnf配置（64G内存8CPU）

路径/fgedudb/mysql97/my.cnf；基础参数和8.4保持完全一致，仅超图优化器默认关闭，用于公平对比。

[mysqld]
user=mysql
port=33097
pid‑file=/fgedudb/mysql97/mysql.pid
socket=/fgedudb/mysql97/mysql.sock
datadir=/fgedudb/mysql97/data
basedir=/fgedudb/mysql97
tmpdir=/fgedudb/mysql97/tmp

log_bin=/fgedudb/mysql97/binlog/mysql‑bin
server‑id=1097
binlog_format=ROW
sync_binlog=1
expire_logs_days=7

#64G内存InnoDB核心参数，与8.4保持一致
innodb_buffer_pool_size=48G
innodb_redo_log_capacity=8G
innodb_log_buffer_size=64M
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
innodb_io_capacity=10000
innodb_io_capacity_max=20000
innodb_write_io_threads=16
innodb_read_io_threads=16

max_connections=2000
open_files_limit=65535
table_open_cache=4096
table_definition_cache=2048
character‑set‑server=utf8mb4
collation‑server=utf8mb4_unicode_ci
skip_name_resolve=ON
#超图优化器默认关闭，测试可以动态开启验证
optimizer_switch='hypergraph_optimizer=off'

[mysqld_safe]
log‑error=/fgedudb/mysql97/log/mysqld.err

网上搜索风哥教程可以学习全套数据库教程

2.5 初始化实例，创建业务账号

在fgedu‑net‑cn1主机初始化MySQL8.4实例：

/fgedudb/mysql84/bin/mysqld --defaults‑file=/fgedudb/mysql84/my.cnf --initialize
systemctl start mysqld84

登录MySQL8.4，创建数据库fgedudb，业务账号fgedu：

CREATE DATABASE fgedudb;
CREATE USER 'fgedu'@'%' IDENTIFIED BY 'Fgedu@2026';
GRANT ALL ON fgedudb.* TO 'fgedu'@'%';
GRANT PROCESS,REPLICATION CLIENT ON *.* TO 'fgedu'@'%';
FLUSH PRIVILEGES;

MySQL9.7实例初始化操作：

/fgedudb/mysql97/bin/mysqld --defaults‑file=/fgedudb/mysql97/my.cnf --initialize
systemctl start mysqld97

同样执行SQL创建fgedudb库，fgedu账号，密码Fgedu@2026。

2.6 fgedu‑net‑cn2压测客户端安装工具

在压测主机fgedu‑net‑cn2安装sysbench依赖：

curl -s [https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh](https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh) | bash
yum install -y sysbench bzr git gcc make
sysbench --version

安装tpcc‑mysql工具：

bzr branch lp:~percona‑dev/perconatools/tpcc‑mysql
cd tpcc‑mysql/src
make

编译完成后上层目录生成tpcc_load、tpcc_start二进制程序。

三、实战一：sysbench基准测试 MySQL8.4环境完整演练

本套实战全部操作执行在压测客户端fgedu‑net‑cn2主机，访问远端数据库主机fgedu‑net‑cn1的33084端口MySQL8.4实例。
sysbench标准测试分为三个阶段：prepare（生成测试数据）、run（正式压测）、cleanup（清理测试数据）。

3.1 prepare准备阶段，生成OLTP读写混合测试数据集

本案例生成16张测试表，每张表2000000行记录，总数据集约70GB，大于48G innodb_buffer_pool_size，模拟冷热混合业务场景。

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 \
--mysql‑port=33084 \
--mysql‑db=fgedudb \
--mysql‑user=fgedu \
--mysql‑password='Fgedu@2026' \
--tables=16 \
--table‑size=2000000 \
--threads=16 \
prepare

等待prepare执行完成，登录MySQL8.4实例，校验表数量与数据行数。

USE fgedudb;
SHOW TABLES;
SELECT COUNT(*) FROM sbtest1;

3.2 数据库预热操作（重要步骤）

数据集70GB，InnoDB buffer pool只有48G；需要执行一轮查询，把热点索引数据加载进缓冲池。在fgedu‑net‑cn2执行sysbench只读短时间压测做预热。

sysbench /usr/share/sysbench/oltp_read_only.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33084 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 --table‑size=2000000 \
--threads=32 --time=120 --report‑interval=10 run

预热运行120秒结束，此时InnoDB缓冲池已经缓存热点索引数据。

3.3 监控指标采集脚本准备（fgedu‑net‑cn1被测数据库主机）

编写简单监控脚本/fgedudb/scripts/bench_monitor.sh，采集iostat、vmstat、mysql状态，输出日志，压测前后启动停止。

#!/bin/bash
LOG_DIR=/fgedudb/bench_log84
mkdir -p ${LOG_DIR}
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
iostat -x 5 > ${LOG_DIR}/iostat_${TIMESTAMP}.log &
VMSTAT_PID=$!
vmstat 5 > ${LOG_DIR}/vmstat_${TIMESTAMP}.log &
IOSTAT_PID=$!
echo $VMSTAT_PID $IOSTAT_PID > ${LOG_DIR}/monitor.pid

赋予执行权限，压测开始前后台启动监控：

chmod +x /fgedudb/scripts/bench_monitor.sh
/fgedudb/scripts/bench_monitor.sh

压测结束之后杀掉监控进程：

kill -9 $(cat /fgedudb/bench_log84/monitor.pid)

风哥 itpux‑com

3.4 OLTP读写混合压测，多并发梯度测试

业务基准测试，不能仅仅跑单并发，要做梯度并发测试，并发线程依次设置：8、16、32、64、128、256；每个并发压测运行300秒，输出日志保存。下面示例以并发64线程命令演示，其他并发修改--threads参数即可。

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 \
--mysql‑port=33084 \
--mysql‑db=fgedudb \
--mysql‑user=fgedu \
--mysql‑password='Fgedu@2026' \
--tables=16 \
--table‑size=2000000 \
--threads=64 \
--time=300 \
--report‑interval=10 \
--histogram=on \
run > /fgedudb/bench_log84/oltp_rw_thread64.log

参数说明：
--time=300 压测持续300秒；
--report‑interval=10 每10秒输出一次中间统计；
--histogram=on 输出延迟直方图，便于分析延迟分布。

压测输出样例关键片段：

SQL statistics:
    queries performed:
        read:                            1754286
        write:                           501224
        other:                           250612
        total:                           2506122
    transactions:                        125306  (417.65 per sec.)
    queries:                             2506122 (8352.98 per sec.)
Latency (ms):
         min:                                    0.82
         avg:                                   14.90
         max:                                  421.74
         95th percentile:                       34.67
         99th percentile:                       72.13

重点记录：TPS、QPS、p95、p99延迟。

3.5 只读场景压测、只写场景压测

只读OLTP场景命令：

sysbench /usr/share/sysbench/oltp_read_only.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33084 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 --table‑size=2000000 --threads=64 --time=300 --report‑interval=10 run > /fgedudb/bench_log84/oltp_ro_thread64.log

只写OLTP场景命令：

sysbench /usr/share/sysbench/oltp_write_only.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33084 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 --table‑size=2000000 --threads=64 --time=300 --report‑interval=10 run > /fgedudb/bench_log84/oltp_wo_thread64.log

3.6 压测完成清理测试数据cleanup

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33084 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 cleanup

四、实战二：sysbench基准测试 MySQL9.7环境完整演练

风哥教程 113257174

本实战在fgedu‑net‑cn2压测客户端，访问fgedu‑net‑cn1主机33097端口MySQL9.7实例。硬件、参数、数据集大小、并发线程、运行时长全部和MySQL8.4保持完全一致，保障两套版本可公平对比。

4.1 prepare准备数据集

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 \
--mysql‑port=33097 \
--mysql‑db=fgedudb \
--mysql‑user=fgedu \
--mysql‑password='Fgedu@2026' \
--tables=16 \
--table‑size=2000000 \
--threads=16 \
prepare

4.2 MySQL9.7实例数据预热

sysbench /usr/share/sysbench/oltp_read_only.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33097 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 --table‑size=2000000 \
--threads=32 --time=120 run

4.3 启动监控脚本（fgedu‑net‑cn1主机）

LOG_DIR=/fgedudb/bench_log97
mkdir -p ${LOG_DIR}
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
iostat -x 5 > ${LOG_DIR}/iostat_${TIMESTAMP}.log &
vmstat 5 > ${LOG_DIR}/vmstat_${TIMESTAMP}.log &
echo $! > ${LOG_DIR}/monitor.pid

4.4 OLTP读写混合梯度压测，示例64线程

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 \
--mysql‑port=33097 \
--mysql‑db=fgedudb \
--mysql‑user=fgedu \
--mysql‑password='Fgedu@2026' \
--tables=16 \
--table‑size=2000000 \
--threads=64 \
--time=300 \
--report‑interval=10 \
--histogram=on \
run > /fgedudb/bench_log97/oltp_rw_thread64.log

依次完成8、16、32、64、128、256并发；再分别执行只读、只写压测，日志保存至/fgedudb/bench_log97/目录。

4.5 开启Hypergraph超图优化器对比测试（MySQL9.7特有）

MySQL9.7支持超图优化器，我们可以动态开启，针对多表JOIN场景做一组对比。会话级别开启超图优化器，编写sysbench自定义lua脚本，或者直接mysql客户端执行全局开关。

SET PERSIST optimizer_switch='hypergraph_optimizer=on';

开启之后，重新运行多JOIN业务场景压测，对比开启前后吞吐量与延迟差异，部分复杂查询性能提升，简单OLTP场景变化不大。测试完成清理数据。

sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql‑host=fgedu‑net‑cn1 --mysql‑port=33097 --mysql‑db=fgedudb \
--mysql‑user=fgedu --mysql‑password='Fgedu@2026' \
--tables=16 cleanup

风哥数据库教程 itpux‑com

五、实战三：tpcc‑mysql电商业务模型基准测试（MySQL8.4与MySQL9.7）

TPC‑C标准模拟电商业务：仓库、客户、订单、新订单、库存、支付，包含事务、外键约束，相比sysbench简单oltp更加贴近真实复杂业务逻辑。tpcc‑mysql工具部署于fgedu‑net‑cn2压测客户端。

5.1 MySQL8.4 tpcc‑mysql完整实战

1. 在MySQL8.4（33084端口）fgedudb库导入tpcc建表语句，在fgedu‑net‑cn2执行：

cd tpcc‑mysql
mysql -h fgedu‑net‑cn1 -P33084 -ufgedu -p'Fgedu@2026' fgedudb < create_table.sql
mysql -h fgedu‑net‑cn1 -P33084 -ufgedu -p'Fgedu@2026' fgedudb < add_fkey_idx.sql

2. 加载数据，‑w代表仓库数量，本次设置20个仓库，生成业务测试数据集。

./tpcc_load -h fgedu‑net‑cn1 -P33084 -d fgedudb -u fgedu -p 'Fgedu@2026' -w 20

3. 正式tpcc压测，‑w仓库数20，压测时长300秒。

./tpcc_start -h fgedu‑net‑cn1 -P33084 -d fgedudb -u fgedu -p 'Fgedu@2026' -w 20 -c 32 -r 60 -l 300 > /fgedudb/bench_log84/tpcc_w20_c32.log

参数解释：
‑c 32 并发线程32；‑r 60预热60秒；‑l 300压测运行300秒。
tpcc输出关键指标为New‑Order每秒完成事务数，是TPC‑C标准性能指标。

5.2 MySQL9.7 tpcc‑mysql实战

同样操作，连接33097端口MySQL9.7实例，‑w同样20仓库，并发、预热、运行时间和8.4完全一致。

cd tpcc‑mysql
mysql -h fgedu‑net‑cn1 -P33097 -ufgedu -p'Fgedu@2026' fgedudb < create_table.sql
mysql -h fgedu‑net‑cn1 -P33097 -ufgedu -p'Fgedu@2026' fgedudb < add_fkey_idx.sql

./tpcc_load -h fgedu‑net‑cn1 -P33097 -d fgedudb -u fgedu -p 'Fgedu@2026' -w 20

./tpcc_start -h fgedu‑net‑cn1 -P33097 -d fgedudb -u fgedu -p 'Fgedu@2026' -w 20 -c 32 -r 60 -l 300 > /fgedudb/bench_log97/tpcc_w20_c32.log

上51CTO搜索风哥可以学习全套数据库教程

六、实战四：mysqlslap快速简易并发基准测试

mysqlslap属于MySQL自带工具，无需额外安装，适合快速简单并发验证，不适合深度正式基准测试。演示MySQL8.4实例执行，fgedu‑net‑cn2执行。

mysqlslap \
--host=fgedu‑net‑cn1 \
--port=33084 \
--user=fgedu \
--password='Fgedu@2026' \
--concurrency=16,32,64 \
--iterations=3 \
--auto‑generate‑sql \
--number‑of‑queries=10000 \
--create‑schema=fgedudb

‑‑concurrency=16,32,64多组并发；‑‑iterations=3每个并发执行3轮取平均值；工具自动生成SQL负载，输出平均执行时间。MySQL9.7执行仅修改端口33097即可。

七、实战五：基准测试结果分析、指标比对、标准化报告输出

7.1 数据清洗过滤

sysbench每10秒输出指标，最开始30‑60秒属于系统预热阶段，这部分数据要丢弃，只统计压测稳定之后的指标。不能直接拿最终汇总一行，当测试中间出现性能抖动，中间分段日志可以观察抖动发生的时间点，结合iostat/vmstat日志定位抖动根因（脏页刷盘、磁盘IO尖峰、锁冲突）。

7.2 MySQL8.4与MySQL9.7版本比对表格模板

风哥教程本文强调：版本对比结论必须写明约束条件。示例：“在p99延迟小于40ms约束条件，64并发线程，70GB数据集环境，MySQL9.7 OLTP读写混合TPS较MySQL8.4提升约25%”，不能简单写“9.7性能比8.4快”。

7.3 定位性能瓶颈分析思路

1. CPU瓶颈：数据库主机CPU持续大于85%，iowait很低；瓶颈在CPU计算，SQL解析、锁latch竞争；可以观察Performance_schema定位热点SQL。
2. IO瓶颈：%util接近100%，iowait高，CPU空闲；磁盘存储IO成为瓶颈；更换更高性能SSD或者优化InnoDB刷盘参数。
3. 锁瓶颈：CPU和IO都空闲，TPS上不去，p99延迟很高；查看show engine innodb status，行锁等待严重，业务SQL存在热点行更新冲突。

八、实战六：参数调优对比实验实战

基准测试重要价值：量化参数修改带来性能变化。举个实战示例，对比innodb_flush_log_at_trx_commit=1与innodb_flush_log_at_trx_commit=2性能差异，以MySQL8.4实例演示。

1. my.cnf设置innodb_flush_log_at_trx_commit=1，重启实例；执行完整sysbench读写混合压测，保存日志。
2. 修改参数innodb_flush_log_at_trx_commit=2，重启实例；保持数据集、并发、运行时长全部不变，只修改这一个参数；重新执行压测，保存日志。
3. 对比两组TPS、延迟数据，得到参数修改的性能收益，同时记录参数带来的数据丢失风险（设置为2操作系统崩溃最多丢失1秒数据）。

网上搜索风哥教程可以学习全套数据库教程

风哥针对本文总结

风哥教程本文完整讲解MySQL性能基准测试整套知识，从基准测试理论定义、测试分类、核心指标体系、MySQL8.4与MySQL9.7版本差异，再到完整大规模实战操作。基准测试不是简单把数据库压到最高TPS，一套有效的基准测试必须绑定延迟约束条件，脱离p95/p99延迟单纯讨论吞吐量没有业务落地价值。

风哥教程本文实战环境严格隔离压测客户端与被测数据库主机，使用fgedu‑net‑cn1、fgedu‑net‑cn2两台主机；全部配置基于64G内存8CPU硬件规格；路径统一替换为/fgedudb；实例数据库名fgedudb，账号fgedu；MySQL8.4、MySQL9.7两套版本案例各占一半，保证版本对比的公平性。整套实战覆盖sysbench OLTP多场景压测、tpcc‑mysql电商业务模型、mysqlslap简易压测，包含prepare、预热、run、cleanup完整流程，配套操作系统、数据库指标采集方案，以及标准化测试报告输出模板。

风哥教程本文再次强调基准测试高频踩坑：缺少数据预热、测试运行时间太短、压测工具与数据库部署同一台机器、数据集过小全部落在操作系统缓存、对比实验变量不唯一、只看TPS忽略延迟分位数。基准测试得到的数据，可用于硬件采购评估、数据库版本升级风险评估、数据库参数调优、业务容量规划。基准测试是DBA的基础能力，所有版本升级、重大参数变更之前，都必须先在隔离测试环境执行基准测试，验证性能与风险之后再落地生产。本套风哥教程可以把本文所有脚本直接复制到测试环境复现整套基准测试流程。