--- title: mysql性能测试 tags: - mysql cover: 'https://picsum.photos/400' abbrlink: cfc5884dd date: 2025-03-30 20:14:35 --- mysql性能测试 以下是一些常用的 MySQL 压测工具： 1. \*\*mysqlslap\*\*: - 这是 MySQL 官方自带的一个轻量级压力测试工具，从 MySQL 5.1.4 版本开始提供。 - 它可以模拟多个客户端并发连接服务器，并执行指定的 SQL 查询（可以是自动生成的模式和数据查询，也可以是自定义 SQL 语句）。 - 使用简单，适合进行基本的负载测试和模式性能比较。 2. \*\*SysBench\*\*: - 这是一个非常流行且功能强大的跨平台、多线程基准测试工具，并非专门为 MySQL 设计，但广泛用于测试数据库（包括 MySQL、PostgreSQL 等）、CPU、内存、文件 I/O 等。 - 针对 MySQL，SysBench 提供了 OLTP（在线事务处理）测试模式，可以模拟复杂的数据库工作负载。 - 配置灵活，可以自定义测试参数，如线程数、测试时间、表大小、事务类型等。是评估 MySQL 性能最常用的工具之一。 3. \*\*BenchmarkSQL\*\*: - 这是一个开源的、模拟 TPC-C 基准测试规范的工具。TPC-C 是一个衡量在线事务处理系统性能的行业标准。 - 虽然名字中没有 MySQL，但它可以配置为针对多种数据库运行，包括 MySQL。 - 它模拟一个复杂的批发供应商业务场景，包含多种事务类型，能较好地反映真实世界的 OLTP 负载。 4. \*\*HammerDB\*\*: - 与 BenchmarkSQL 类似，HammerDB 也是一个流行的开源数据库负载测试和基准测试工具。 - 支持多种数据库，包括 MySQL。 - 它同样支持 TPC-C 和 TPC-H（决策支持/数据仓库）基准测试规范，可以模拟不同类型的数据库工作负载。 - 提供了图形用户界面（GUI）和命令行接口（CLI）。 5. \*\*tpcc-mysql\*\*: - 这是一个专门为 MySQL 实现 TPC-C 基准测试的工具集，由 Percona 开发和维护（尽管可能需要查找最新版本或替代方案）。 - 专注于在 MySQL 上准确模拟 TPC-C 测试。 \*\*选择哪个工具？\*\* - \*\*简单、快速测试或验证\*\*：\`mysqlslap\` 是个不错的起点，因为它已经包含在 MySQL 发行版中。 - \*\*全面、复杂的 OLTP 性能评估\*\*：\`SysBench\` 是最常用和推荐的选择，因为它灵活且强大。 - \*\*模拟标准 TPC-C 负载\*\*：\`BenchmarkSQL\` 或 \`HammerDB\` 是更合适的选择，它们严格遵循 TPC-C 规范。\`HammerDB\` 还支持 TPC-H ---- ## mysqlslap mysqlslap --user=root --password=12346 --auto-generate-sql 没有自带。需要安装server \`\`\`bash root@txpc:\~# mysqlslap -hlocalhost -uroot -p12346 --concurrency=100 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=5000 mysqlslap: \[Warning\] Using a password on the command line interface can be insecure. Benchmark Running for engine innodb Average number of seconds to run all queries: 0.362 seconds Minimum number of seconds to run all queries: 0.362 seconds Maximum number of seconds to run all queries: 0.362 seconds Number of clients running queries: 100 Average number of queries per client: 50 \`\`\` ### 解读 ### MySQLSlap 测试结果深度解读 --- #### \*\*关键指标概览\*\* \| 指标名称 \| 数值 \| 性能评价等级 \| \| ------- \| ---------- \| ------ \| \| 总查询量 \| 5000次 \| 基准测试量 \| \| 并发客户端数 \| 100个 \| 高并发场景 \| \| 平均执行时间 \| 0.362秒 \| 极优 \| \| 单客户端查询量 \| 50次/客户端 \| 轻量级负载 \| \| 估算QPS \| ≈13,812次/秒 \| 高性能区间 \| --- ### \*\*核心数据解析\*\* #### 1. \*\*执行效率分析\*\* text \`\`\` 总耗时 0.362秒 完成 5000次查询 =\> 计算吞吐量：5000 / 0.362 ≈ 13,812 QPS \`\`\` - \*\*对比SysBench结果\*\*（前次测试45,897 QPS）： - 吞吐量差异源于\*\*负载类型不同\*\*： - SysBench：纯读操作（\`oltp_read_only\`） - MySQLSlap：混合负载（\`--auto-generate-sql-load-type=mixed\` 含写操作） #### 2. \*\*并发能力验证\*\* text \`\`\` 100并发客户端 × 50次查询 = 5000次总查询 平均响应时间 \<0.5秒 \`\`\` - \*\*高并发表现\*\*： - 100个连接下无连接池耗尽现象 - 未出现 \`Too many connections\` 错误 - 线程处理效率：100线程/0.362s ≈ 276线程/秒 #### 3. \*\*负载类型特征\*\* text \`\`\` --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement \`\`\` - \*\*自动生成的SQL包含\*\*： - INSERT（自增主键操作） - UPDATE（基于随机WHERE条件） - SELECT（范围查询） - 隐式索引维护成本 --- ### \*\*性能亮点与潜在问题\*\* #### ✅ \*\*优势表现\*\* 1. \*\*锁竞争控制优秀\*\* - 100并发下未出现死锁/锁超时（\`SHOW ENGINE INNODB STATUS\` 可验证） 2. \*\*连接池效率\*\* - 线程复用能力：\`thread_cache_size\` 配置合理 3. \*\*写入性能\*\* - 自增主键插入效率：推测使用独立表空间（\`innodb_file_per_table=ON\`） #### ⚠️ \*\*需验证项\*\* 1. \*\*测试深度不足\*\* bash \`\`\` # 建议增加迭代次数 --iterations=10 # 获取稳定平均值 \`\`\` 2. \*\*资源监控缺失\*\* bash \`\`\` # 测试时建议同步监控 vmstat 1 # 查看上下文切换 iostat -xmt 1 # 分析磁盘利用率 \`\`\` 3. \*\*真实场景差异\*\* - 自动生成的SQL模式与业务真实查询存在差异 - 建议补充自定义SQL测试： bash \`\`\` --create-schema=your_db \\ --query="SELECT \* FROM orders WHERE user_id=..." \\ \`\`\` --- ### \*\*配置优化建议\*\* #### 1. InnoDB参数调优 ini \`\`\` # my.cnf 优化方向 innodb_flush_log_at_trx_commit=2 # 测试环境可放宽持久化要求 innodb_buffer_pool_size=4G # 需大于测试数据总量 innodb_thread_concurrency=0 # 禁用并发限制 \`\`\` #### 2. 压力测试进阶方案 bash \`\`\` # 梯度压力测试（观察性能拐点） for thd in 50 100 150 200; do mysqlslap --concurrency=$thd --iterations=3 ... done # 持久压力测试（检测内存泄漏） --iterations=100 --number-of-queries=1000000 \`\`\` #### 3. 安全警告处理 bash \`\`\` # 改用安全认证方式（消除密码泄露风险） mysql_config_editor set --login-path=local \\ --host=localhost --user=root --password # 执行时使用： mysqlslap --login-path=local ... \`\`\` --- ### \*\*性能指标参考基准\*\* \| 测试场景 \| 合理QPS范围 \| 当前结果状态 \| \| ---------- \| ------------- \| ------ \| \| 混合负载（OLTP） \| 5,000-15,000 \| 优秀 \| \| 纯读负载 \| 15,000-50,000 \| 需单独测试 \| \| 批量写入 \| 1,000-5,000 \| 未覆盖 \| --- ### \*\*可视化分析建议\*\* 1. \*\*绘制并发-吞吐量曲线\*\* bash \`\`\` # 生成数据文件 seq 50 50 200 \| xargs -I{} mysqlslap --concurrency={} ... \>\> result.log # 使用gnuplot绘制 plot "result.log" using 1:2 with lines title 'QPS' \`\`\` 2. \*\*火焰图分析\*\* bash \`\`\` perf record -g -p $(pidof mysqld) -- sleep 60 perf script \| FlameGraph/stackcollapse-perf.pl \| FlameGraph/flamegraph.pl \> profile.svg \`\`\` 当前测试结果表明数据库在\*\*高并发混合负载\*\*场景下表现优异，但需注意自动生成测试的局限性。建议结合SysBench的\`oltp_read_write\`测试进行交叉验证，并持续监控\`Innodb_row_lock_time\`等关键指标。 ## SysBench https://github.com/ 先准备数据 \`\`\`bash mysql -uroot -p123456 -hlocalhost -P3306 -e "CREATE DATABASE sbtest_db;" \`\`\` \`\`\`bash sysbench oltp_read_only --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=sbtest_db --table-size=100000 --tables=8 prepare \`\`\` \`\`\`bash root@txpc:\~# sysbench oltp_read_only --db-driver=mysql --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=sbtest_db --time=60 --threads=4 --report-interval=5 --rand-type=uniform run sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 4 Report intermediate results every 5 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! \[ 5s \] thds: 4 tps: 2837.09 qps: 45401.49 (r/w/o: 39726.51/0.00/5674.99) lat (ms,95%): 1.79 err/s: 0.00 reconn/s: 0.00 \[ 10s \] thds: 4 tps: 2932.13 qps: 46910.46 (r/w/o: 41046.40/0.00/5864.06) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 \[ 15s \] thds: 4 tps: 2938.03 qps: 47012.03 (r/w/o: 41135.77/0.00/5876.25) lat (ms,95%): 1.67 err/s: 0.00 reconn/s: 0.00 \[ 20s \] thds: 4 tps: 2530.70 qps: 40488.52 (r/w/o: 35427.13/0.00/5061.39) lat (ms,95%): 2.00 err/s: 0.00 reconn/s: 0.00 \[ 25s \] thds: 4 tps: 2846.61 qps: 45544.18 (r/w/o: 39850.95/0.00/5693.22) lat (ms,95%): 1.76 err/s: 0.00 reconn/s: 0.00 \[ 30s \] thds: 4 tps: 2933.59 qps: 46939.29 (r/w/o: 41072.11/0.00/5867.19) lat (ms,95%): 1.67 err/s: 0.00 reconn/s: 0.00 \[ 35s \] thds: 4 tps: 2875.60 qps: 46012.40 (r/w/o: 40261.20/0.00/5751.20) lat (ms,95%): 1.76 err/s: 0.00 reconn/s: 0.00 \[ 40s \] thds: 4 tps: 2887.62 qps: 46202.14 (r/w/o: 40426.90/0.00/5775.24) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 \[ 45s \] thds: 4 tps: 2912.66 qps: 46602.60 (r/w/o: 40777.28/0.00/5825.33) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 \[ 50s \] thds: 4 tps: 2903.17 qps: 46447.69 (r/w/o: 40641.56/0.00/5806.14) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 \[ 55s \] thds: 4 tps: 2905.33 qps: 46487.33 (r/w/o: 40676.46/0.00/5810.87) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 \[ 60s \] thds: 4 tps: 2921.29 qps: 46737.24 (r/w/o: 40894.86/0.00/5842.38) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00 SQL statistics: queries performed: read: 2409750 write: 0 other: 344250 total: 2754000 transactions: 172125 (2868.60 per sec.) queries: 2754000 (45897.64 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 60.0022s total number of events: 172125 Latency (ms): min: 0.41 avg: 1.39 max: 14.46 95th percentile: 1.76 sum: 239811.61 Threads fairness: events (avg/stddev): 43031.2500/270.82 execution time (avg/stddev): 59.9529/0.00 \`\`\` ## 解读 ### SysBench 测试结果深度解读 --- #### \*\*关键指标概览\*\* \| 指标名称 \| 数值范围/平均值 \| 性能评价等级 \| \| ----------- \| ------------ \| ------ \| \| 事务吞吐量 (TPS) \| 2868.60/sec \| 优秀 \| \| 查询吞吐量 (QPS) \| 45897.64/sec \| 卓越 \| \| 95%延迟 \| 1.76ms \| 极佳 \| \| 最大延迟 \| 14.46ms \| 正常波动 \| --- ### \*\*实时监控数据分析\*\* text \`\`\` \[ 5s \] thds:4 tps:2837 qps:45401 lat(95%):1.79ms \[ 10s \] thds:4 tps:2932 qps:46910 lat(95%):1.70ms ...（中间波动）... \[ 60s \] thds:4 tps:2921 qps:46737 lat(95%):1.70ms \`\`\` 1. \*\*稳定性表现\*\* - TPS 波动范围 ±3%（2837\~2933），属于\*\*优秀稳定区间\*\* - 第20秒出现TPS下降至2530（可能是后台进程干扰） - 自动恢复能力：1个报告周期内恢复基准水平 2. \*\*资源利用率特征\*\* - 95%延迟始终 \<2ms，说明\*\*未触及硬件瓶颈\*\* - 最大延迟14.46ms，符合OLTP系统黄金标准（\<20ms） --- ### \*\*核心性能指标详解\*\* #### \*\*1. 事务吞吐量 (TPS)\*\* - \*\*2868.60事务/秒\*\* 每个事务包含： text \`\`\` 14次读操作 (SELECT) 1次范围查询 (SELECT...WHERE id BETWEEN) 1次统计查询 (SELECT COUNT(\*)) \`\`\` - 折合\*\*每秒完成2868个完整业务事务\*\* - 对比参考值： - 机械硬盘环境：800-1200 TPS - NVMe SSD环境：2500+ TPS（当前结果属于此范畴） #### \*\*2. 查询吞吐量 (QPS)\*\* - \*\*45,897.64查询/秒\*\* 查询类型分布： text \`\`\` 读占比 87.5% (2409750次) 其他操作 12.5% (344250次) \`\`\` - 典型OLTP场景特征：读密集型负载 - 单事务查询量：2754000/172125≈16次/事务 #### \*\*3. 延迟表现\*\* \| 百分位 \| 延迟值 \| 意义 \| \| ---- \| ------- \| ---------- \| \| 最小值 \| 0.41ms \| 理想空载响应 \| \| 平均值 \| 1.39ms \| 系统平均处理能力 \| \| 95%线 \| 1.76ms \| 服务质量保障基准 \| \| 最大值 \| 14.46ms \| 偶发IO等待/锁竞争 \| --- ### \*\*硬件效能评估\*\* 根据指标反推硬件配置： - \*\*CPU\*\*：4核处理器（与线程数匹配）利用率约70-80% - \*\*存储\*\*：NVMe SSD（随机读IOPS \>5万） - \*\*内存\*\*：innodb_buffer_pool_size ≥8GB（缓存命中率\>99%） - \*\*网络\*\*：本地localhost连接，无带宽瓶颈 --- ### \*\*优化建议\*\* 1. \*\*垂直扩展\*\* bash \`\`\` --threads=8 # 提升至CPU物理核心数2倍 --table-size=500000 # 扩大测试数据量 \`\`\` 2. \*\*压力测试\*\* bash \`\`\` sysbench oltp_read_write.lua # 切换到读写混合模式 --time=300 # 延长测试时间观察稳定性 --rate=5000 # 限流测试突发处理能力 \`\`\` 3. \*\*监控联动\*\* bash \`\`\` # 实时监控工具组合 dstat -tcmnd --disk-util # 资源监控 mytop -u root -p 123456 # MySQL线程观察 iostat -xmt 1 # 磁盘性能分析 \`\`\` --- ### \*\*风险预警信号\*\* \| 现象 \| 当前状态 \| 预警阈值 \| \| ---- \| ---- \| -------- \| \| 错误率 \| 0% \| \>0.1%需排查 \| \| 连接中断 \| 0次 \| \>1次/分钟 \| \| 最大延迟 \| 14ms \| \>50ms异常 \| 当前测试结果完全处于\*\*绿色安全区间\*\*，系统具备处理更大负载的潜力。建议在业务高峰时段进行压力测试，验证系统极限容量。 ## BenchmarkSQL \[Home - BenchmarkSQL\](https://benchmarksql.readthedocs.io/en/latest/) 主流数据库。 以下是根据你提供的 \*\*BenchmarkSQL MySQL 版仓库\*\* (\[enhancedformysql/benchmarksql\](https://github.com/enhancedformysql/benchmarksql.git)) 整理的详细安装与运行指南： --- ### 前置条件 1. \*\*JDK 7\*\* 确保已安装 JDK 7（仅支持此版本）： bash \`\`\` sudo apt install openjdk-7-jdk # 验证版本 java -version \`\`\` 2. \*\*MySQL 数据库\*\* 已安装 MySQL 并启动服务： bash \`\`\` sudo apt install mysql-server sudo systemctl start mysql \`\`\` --- ### 1. 克隆仓库与编译 bash \`\`\` git clone https://github.com/enhancedformysql/benchmarksql.git cd benchmarksql ant # 使用 Apache Ant 编译项目 \`\`\` 编译成功后，生成 \`dist/BenchmarkSQL-5.0.jar\`。 --- ### 2. 配置 MySQL 用户与数据库 1. \*\*登录 MySQL\*\*： \`\`\` mysql -u root -p \`\`\` 2. \*\*创建用户和数据库\*\*： sql \`\`\` CREATE USER 'tpcc'@'%' IDENTIFIED BY 'tpcc_password'; GRANT ALL PRIVILEGES ON \*.\* TO 'tpcc'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES; CREATE DATABASE benchmarksql; \`\`\` --- ### 3. 配置 BenchmarkSQL 1. \*\*进入 \`run\` 目录\*\*： \`\`\` cd run \`\`\` 2. \*\*复制并编辑配置文件\*\*： bash \`\`\` cp props.my props.mysql nano props.mysql # 或使用其他编辑器 \`\`\` 3. \*\*修改配置参数\*\*（关键项）： properties \`\`\` db=mysql driver=com.mysql.jdbc.Driver conn=jdbc:mysql://localhost:3306/benchmarksql user=tpcc password=tpcc_password warehouses=10 # 仓库数量（根据测试规模调整） loadWorkers=4 # 数据加载并发线程数 terminals=10 # 并发数据库连接数 runTxnsPerTerminal=1000 # 每个终端运行的事务数 \`\`\` --- ### 4. 初始化数据库 1. \*\*创建表结构\*\*： bash \`\`\` ./runSQL.sh props.mysql sql.mysql/tableCreates.sql \`\`\` 2. \*\*创建索引\*\*： bash \`\`\` ./runSQL.sh props.mysql sql.mysql/indexCreates.sql \`\`\` 3. \*\*加载测试数据\*\*： \`\`\` ./runLoader.sh props.mysql \`\`\` --- ### 5. 运行基准测试 \`\`\` ./runBenchmark.sh props.mysql \`\`\` 测试完成后会输出类似结果： txt \`\`\` Measured tpmC (NewOrders) = 179.55 Measured tpmTOTAL = 329.17 \`\`\` --- ### 6. 查看结果 - \*\*日志文件\*\*：在 \`results\` 目录中查看详细日志（如 \`my_result_\*/output.log\`）。 - \*\*生成 HTML 报告\*\*（需安装 R）： bash \`\`\` ./generateReport.sh my_result_12345 \`\`\` --- ### 常见问题 #### 1. \*\*JDK 版本不兼容\*\* 确保使用 \`openjdk-7-jdk\`，若系统已安装其他版本，可手动指定： bash \`\`\` export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 \`\`\` #### 2. \*\*MySQL 连接失败\*\* - 检查 MySQL 用户权限是否允许远程连接（如 \`'tpcc'@'%'\`）。 - 确保 MySQL 监听地址在 \`my.cnf\` 中配置为 \`bind-address = 0.0.0.0\`。 #### 3. \*\*驱动缺失\*\* 将 MySQL JDBC 驱动（如 \`mysql-connector-java-5.1.xx.jar\`）复制到 \`lib\` 目录： bash \`\`\` cp /path/to/mysql-connector.jar ./lib/ \`\`\` #### 4. \*\*性能调优\*\* - 增加 \`warehouses\` 和 \`terminals\` 参数以模拟高负载。 - 调整 MySQL 配置（如 \`innodb_buffer_pool_size\`）以优化性能。 --- ### 附：清理测试数据 bash \`\`\` mysql -u root -p -e "DROP DATABASE benchmarksql;" \`\`\` --- 通过以上步骤，你可以在 MySQL 上完成 BenchmarkSQL 的安装与基准测试。注意此版本仅支持 \*\*Read Committed\*\* 隔离级别，确保 MySQL 配置一致。 ### 解读： 以下是对 \`./runBenchmark.sh props.mysql\` 输出的关键信息解读： --- ### 一、测试配置信息 1. \*\*基准测试工具\*\* \`\`\` BenchmarkSQL v5.0 \`\`\` 使用的 BenchmarkSQL 版本为 5.0，支持 TPC-C 基准测试模型。 2. \*\*数据库连接配置\*\* text \`\`\` db=mysql driver=com.mysql.jdbc.Driver conn=jdbc:mysql://localhost:3306/benchmarksql?... user=tpcc warehouses=20 terminals=20 runMins=5 \`\`\` - 测试目标为 \*\*MySQL\*\* 数据库。 - 使用 \`tpcc\` 用户连接本地 MySQL 的 \`benchmarksql\` 数据库。 - 配置 \*\*20 个仓库（warehouses）\*\* 和 \*\*20 个并发终端（terminals）\*\* 。 - 测试持续时间为 \*\*5 分钟（runMins=5）\*\* 。 --- ### 二、性能指标解读 1. \*\*事务吞吐量（tpmTOTAL）\*\* text \`\`\` Term-00, Running Average tpmTOTAL: 7686.72 Current tpmTOTAL: 253212 \`\`\` - \*\*Running Average tpmTOTAL\*\*: 平均每分钟总事务数（所有事务类型），最终稳定在约 \*\*7,686.72 tpm\*\*。 - \*\*Current tpmTOTAL\*\*: 测试期间累计完成的总事务数为 \*\*253,212 次\*\*。 2. \*\*新订单吞吐量（tpmC）\*\* text \`\`\` Measured tpmC (NewOrders) = 7686.72 \`\`\` - \*\*tpmC\*\* 是 TPC-C 基准的核心指标，表示每分钟处理的 \*\*新订单事务数\*\*。 - 测试结果为 \*\*7,686.72 tpmC\*\*，反映数据库在 OLTP 场景下的处理能力。 3. \*\*事务权重分配\*\* text \`\`\` newOrderWeight=45 paymentWeight=43 orderStatusWeight=4 deliveryWeight=4 stockLevelWeight=4 \`\`\` - 事务类型比例符合 TPC-C 标准（新订单 45%，支付 43%，其他合计 12%）。 --- ### 三、资源使用情况 1. \*\*内存使用\*\* \`\`\` Memory Usage: 101MB / 154MB \`\`\` - 测试期间 JVM 内存使用峰值约 \*\*101MB\*\*，未超过分配的 \*\*154MB\*\*，无内存溢出风险。 - 内存波动正常（10MB\~100MB），表明垃圾回收机制有效。 2. \*\*测试时间\*\* text \`\`\` Session Start = 2025-03-30 20:45:59 Session End = 2025-03-30 20:50:59 \`\`\` - 实际运行时间严格控制在 \*\*5 分钟\*\*，符合 \`runMins=5\` 的配置。 --- ### 四、测试结果有效性 1. \*\*事务完整性\*\* \`\`\` Transaction Count = 253212 \`\`\` - 所有事务正常提交，无错误回滚记录（如无 \`ERROR\` 日志）。 2. \*\*线程终止状态\*\* text \`\`\` Terminal received stop signal! Waiting for all active transactions to end \`\`\` - 所有并发线程（20 个）在测试结束后正常退出，无残留进程。 --- ### 五、性能优化建议 1. \*\*提升 tpmC\*\* - 增加 \`innodb_buffer_pool_size\`（建议设置为物理内存的 70-80%）。 - 调整 \`innodb_flush_log_at_trx_commit=2\` 以降低事务提交频率（需权衡持久性）。 2. \*\*扩展测试规模\*\* - 增大 \`warehouses\`（仓库数）和 \`terminals\`（并发终端数），模拟更高负载。 - 延长 \`runMins\` 至 60 分钟以上，观察数据库在长时间压力下的稳定性。 3. \*\*监控瓶颈\*\* - 使用 \`SHOW ENGINE INNODB STATUS\` 检查锁竞争、死锁频率。 - 监控 MySQL 的 CPU、I/O 和网络使用率，定位硬件瓶颈。 --- ### 六、结果保存与报告 1. \*\*日志与数据文件\*\* text \`\`\` results/output.log my_result_2025-03-30_204559/data/result.csv \`\`\` - 详细结果保存在 \`my_result_2025-03-30_204559\` 目录中。 2. \*\*生成 HTML 报告\*\* 这里要加bash来执行，不然sh报语法错误 bash \`\`\` bash ./generateReport.sh my_result_2025-03-30_204559 \`\`\` - 需安装 R 语言环境生成可视化报告（包含吞吐量、延迟等图表）。 - sudo apt install r-base !\[2rvudp.png\](https://files.catbox.moe/2rvudp.png) ## HammerDB 3 、构 RR\*SCHEMA选择 ORACLE-\>TPROC-C-\>Schema BuiId- \>Options \[HammerDB 进行数据库压力测试 - 踏雪无痕2017 - 博客园\](https://www.cnblogs.com/oradba/p/15692540.html) After installation double-click on the "Windows Batch File" hammerdb to start hammerdb. 安装后双击 "Windows 批处理文件" hammerdb 以启动 hammerdb。 加载不了库： 对于 HammerDB 支持的所有数据库，必须安装 HammerDB 可用于连接数据库并与之交互的第三方客户端库。请注意，如果您使用官方的 HammerDB Docker 映像，则此步骤已经为您完成，并且所有第三方客户端库都已预安装。此客户端库通常还将与数据库服务器软件一起安装。HammerDB 不会静态链接第三方库以最小化可执行文件大小，并在使用的第三方库中提供灵活性。例如，如果在特定库中检测到错误，则可以升级该错误，而无需重新构建 HammerDB 库。但是，由于 client 库是动态链接的，因此必须已安装正确的 client 库并设置环境变量，以确保 HammerDB 可以找到正确的库。请注意，只需加载您正在测试的数据库的库。 The HammerDB command line tool can be used to check the status of library availability for all databases. HammerDB 命令行工具可用于检查所有数据库的库可用性状态。 To run this utility run the following command 要运行此实用程序，请运行以下命令 ./hammerdbcli and type librarycheck. 并键入 librarycheck。 Checking database library for MySQL Error: failed to load mysqltcl - couldn't load library "C:/Program Files/HammerDB-4.12/lib/mysqltcl3.052/libmysqltcl.dll": this library or a dependent library could not be found in library path Ensure that MySQL client libraries are installed and the location in the PATH environment variable Checking database library for PostgreSQL 搞不了，只能用docker: docker pull tpcorg/hammerdb:mysql docker run --net=host --name hammerdb-cloudtk tpcorg/hammerdb:latest-cloudtk ### .2. CloudTK Web 应用程序 Docker 镜像 HammerDB provides an additional Docker image for running the HammerDB GUI as a Web Application accessed through a web browser. This is particularly useful running in a cloud environment where a local Desktop environment is not readily available. f you want access to functionality such as CPU metrics then you should use the --net-host option. HammerDB 提供了一个额外的 Docker 映像，用于将 HammerDB GUI 作为通过 Web 浏览器访问的 Web 应用程序运行。在本地桌面环境不可用的云环境中运行时，这尤其有用。如果要访问 CPU 指标等功能，则应使用 --net-host 选项。 $ sudo docker run --net=host --name hammerdb-cloudtk tpcorg/hammerdb:latest-cloudtk can't find package limit Running with default file descriptor limit /debug user "debug" password "sycu4xfc.gcw" httpd started on port 8081 secure httpd started on SSL port 8082 Otherwise you can only expose the ports as needed. 否则，您只能根据需要公开端口。 docker run -p 8081:8081 -p 8082:8082 -p 8080:8080 --name hammerdb-cloudtk hammerdb:cloudtk You can connect to port 8081 for an unencrypted connection. Alternatively you can use an encrypted connection on port 8082. By default sample self-signed certificates are installed and these should be replaced by your own. 您可以连接到端口 8081 以获得未加密的连接。或者，您可以在端口 8082 上使用加密连接。默认情况下，会安装示例自签名证书，这些证书应替换为您自己的证书。 \*\*Figure 1.14. CloudTK Launcher\*\* 用无痕浏览器打开 还是用命令行吧，太难搞了。 磁盘IOPS 用htop，可以配置对应的行