简介这是一份面向数据库管理员、测试工程师与IT选型人员的BenchmarkSQL达梦适配版工具包用于对达梦数据库开展标准化基准测试评估其在高并发事务场景下的TPS、响应时间等性能指标并可与Oracle、MySQL、PostgreSQL等主流数据库横向对比。压缩包共94个文件约3.77MB包含11个Java源码、19个class、12个SQL脚本、9个jar依赖及8个sh运行脚本另有properties配置、xml构建文件与dm、ora、pg等数据库专用参数文件覆盖源码、编译产物与运行环境。资源已获800人学习下载提供完整的达梦测试配置与执行链路读者可据此搭建测试环境、自定义工作负载、生成性能报告并借助联系作者说明与README快速排错为数据库选型与性能调优提供可复用的实践参考。1. 达梦数据库跑分这件事为什么我最后选了 BenchmarkSQL 5.0 这个改版手上有一套达梦数据库领导问“性能到底行不行”你总不能拿几句select count(*)糊弄过去。真到选型、验收、调优这种场合需要的是标准化的 TPCC 类负载能出 TPS、能看响应时间、能横向对比 Oracle 和 PostgreSQL。BenchmarkSQL 就是干这个的它是业界用得最广的开源数据库基准测试工具之一原生支持 PostgreSQL、Oracle、Firebird 等而这个版本是专门为达梦数据库做了适配的 5.0 改版压缩包里直接带了props.dm配置模板、达梦专用的建表与加载脚本省掉了自己改 SQL 方言的功夫。它适合三类人正在做达梦选型验证的 DBA、要给达梦做性能基线的运维、以及需要拿达梦和别的库做对比测试的架构师。下面我按“这是什么 → 怎么配 → 怎么跑 → 坑在哪”的顺序把这份资源拆开讲清楚。2. 拆开压缩包目录结构、达梦适配点与运行前置条件2.1 目录里到底有什么哪些是达梦相关的解压benchmarksql-5.0-支持达梦.zip之后根目录下大致是这么几块东西我按用途分一下路径/文件作用达梦相关度run/所有可执行脚本的入口目录高run/props.dm达梦数据库连接与测试参数模板核心run/sql.common/通用建表、索引、外键 SQL中run/sql.dameng/或dameng/达梦方言的 SQL 脚本核心run/funcs.sh脚本公共函数库中src/Java 源码低lib/依赖 jar含log4j-1.2.17.jar、apache-log4j-extras-1.1.jar低dist/benchmarksql-5.0.jar编译好的可执行 jar中doc/、README.TXT、HOW-TO-RUN.txt说明文档中联系作者.txt维护者联系方式低关键就是props.dm和达梦方言 SQL 这两块。原生 BenchmarkSQL 的props.pg里用的是 PostgreSQL 的serial、text这些类型达梦虽然兼容大部分语法但建表语句、序列、索引命名上还是有差异这个改版把这些都替你处理好了你不需要再去手改 DDL。2.2 跑之前必须确认的三件事第一JDK 版本。BenchmarkSQL 5.0 是 Java 写的编译和运行都需要 JDK常见做法是用 JDK 8 或 JDK 11太新的 JDK比如 17 以上在 log4j 1.x 上偶尔会有反射告警能跑但不干净。先确认java -version javac -version两条命令的版本号要一致否则ant编译时会报Unsupported class file major version。第二达梦的 JDBC 驱动。压缩包的lib/里不一定带DmJdbcDriver18.jar达梦官方驱动你需要从达梦安装目录的drivers/jdbc/下拷一份进来。驱动版本要和你的达梦服务端匹配DM8 一般用DmJdbcDriver18.jar。第三数据库侧的准备。达梦这边要提前建好测试用的表空间和用户并且给足权限。BenchmarkSQL 会建表、建索引、加载数据、跑事务用户至少要有CREATE TABLE、CREATE INDEX、INSERT、UPDATE、SELECT、DELETE权限。常见做法是直接给测试用户DBA角色测试完再回收。-- 在达梦里用 SYSDBA 执行 CREATE TABLESPACE TS_BMSQL DATAFILE TS_BMSQL.DBF SIZE 2048 AUTOEXTEND ON; CREATE USER bmsql IDENTIFIED BY Bmsql_123 DEFAULT TABLESPACE TS_BMSQL; GRANT DBA TO bmsql;表空间给 2G 起步因为 TPCC 默认 10 个仓库加载完大概几百 MB仓库数调大后数据量线性增长空间不够会在加载阶段直接失败。2.3 编译与 jar 的取舍压缩包里已经有dist/benchmarksql-5.0.jar理论上可以直接用。但如果你改了源码或者换了 JDK建议重新编译一遍cd benchmarksql-5.0 antant会读build.xml把src/编译到build/再打包到dist/。如果ant没装用系统包管理器装一下即可。编译成功后会看到BUILD SUCCESSFUL。这一步的坑在于build.xml里可能写死了 JDK 路径报错就打开build.xml看property namejavac.path之类的配置改成你本机的JAVA_HOME。3. 配置 props.dm连接串、仓库数与终端数的参数逻辑3.1 props.dm 逐项拆解props.dm是整个测试的控制中心我把它最关键的几行拎出来讲dbdm driverdm.jdbc.driver.DmDriver connjdbc:dm://127.0.0.1:5236/BMSQL userbmsql passwordBmsql_123 warehouses10 terminals10 runMins5 limitTxnsPerMin0dbdm告诉 BenchmarkSQL 走达梦的分支逻辑加载对应的 SQL 方言文件。这一项写错后面会去加载 PostgreSQL 的脚本直接报语法错误。driver达梦 JDBC 驱动类名DM8 就是dm.jdbc.driver.DmDriver别写成dm.jdbc.driver.DmdbDriver那是老版本的类名。conn连接串格式是jdbc:dm://主机:端口/库名达梦默认端口 5236。如果库名和用户名不同这里写的是库名模式名不是用户名。warehouses仓库数决定数据量。1 个仓库约 100MB 数据10 个仓库就是 1GB 左右。仓库数太少压不出并发瓶颈太多加载时间会很长。做基线测试一般 10 到 100 之间。terminals并发终端数也就是模拟的客户端数量。这个值要参考你数据库的 CPU 核数和连接数上限一般设成 CPU 核数的 2 到 4 倍。runMins测试持续分钟数。短测 5 分钟看趋势正式跑 20 到 60 分钟看稳定性。limitTxnsPerMin0不限速让数据库跑满。设成非 0 会限制每分钟事务数一般只在做阶梯压测时用。3.2 连接串的几种写法与常见错误达梦的连接串有几个变体我列一下对比写法含义适用场景jdbc:dm://127.0.0.1:5236不指定库名连默认库单库测试jdbc:dm://127.0.0.1:5236/BMSQL指定库名 BMSQL多库环境jdbc:dm://127.0.0.1:5236?compatibleModeoracle带兼容模式参数从 Oracle 迁移的库最常见的翻车是连接串里带了空格或者密码里有特殊字符没转义。达梦密码如果含、#这类字符在 properties 文件里要小心properties 不认转义建议测试用户用纯字母数字加下划线的密码。3.3 仓库数与终端数的搭配原则这两个参数不是随便填的。仓库数决定数据规模终端数决定并发压力。如果terminals远大于warehouses会出现大量事务在等锁TPS 反而上不去这是典型的资源争用。经验比例是terminals不超过warehouses的 2 倍。比如 10 个仓库终端最多设 20。反过来仓库数很大但终端数很小数据库根本压不满测出来的 TPS 没有参考价值。改完props.dm后建议先跑一次小规模验证warehouses2、terminals2、runMins1确认整条链路通了再放大参数正式跑。4. 建库、加载、跑分三个脚本的执行顺序与参数4.1 建表runDatabaseBuild.sh进入run/目录执行cd run ./runDatabaseBuild.sh props.dm这个脚本会依次做几件事删掉旧表如果存在、按达梦方言建表、建索引、建外键、加载初始数据。加载数据是最耗时的一步10 个仓库大概几分钟到十几分钟取决于磁盘和达梦的配置。脚本执行过程中会打印进度看到Loading data...后面跟着仓库编号在跳说明正常。如果中途报错先看log4j.properties配的日志级别默认是INFO改成DEBUG能看到具体哪条 SQL 挂了。常见错误是表空间不足或用户权限不够报错信息里会带tablespace或privilege关键字。4.2 跑分runBenchmark.sh建库成功后执行./runBenchmark.sh props.dm它会启动terminals个并发线程每个线程循环执行 TPCC 的五种事务新订单、支付、订单状态查询、发货、库存查询。跑满runMins分钟后自动停止并在控制台输出结果。输出里最关键的几个指标Measured tpmC每分钟新订单事务数这是 TPCC 的核心指标越大越好。Measured tpmTOTAL每分钟总事务数。Transaction Mix各类事务的占比正常情况新订单和支付各占 40% 多其余三类占少数。如果占比异常说明某类事务被阻塞了。4.3 清理runDatabaseDestroy.sh测试完想清场执行./runDatabaseDestroy.sh props.dm它会删掉所有 BenchmarkSQL 建的表。注意这个脚本只删表不删表空间和用户表空间要手动清理。4.4 结果怎么读控制台输出是一行行的汇总但真正有用的是最后那段Result。我一般会把输出重定向到文件方便对比多次测试./runBenchmark.sh props.dm 21 | tee result_$(date %Y%m%d_%H%M).log对比两次测试时只看tpmC不够还要看Response Time的分布。如果tpmC高但 90 分位响应时间也高说明是靠堆积并发换来的吞吐实际体验未必好。达梦在高并发下的锁等待是常见瓶颈terminals调大后tpmC不升反降基本就是锁竞争的问题。5. 避坑与排查达梦跑 BenchmarkSQL 最容易翻车的五个点5.1 报错 “Table or view does not exist”现象建表脚本跑到一半报某个表不存在但明明前面建过了。原因达梦默认大小写敏感BenchmarkSQL 的 SQL 里表名是小写而达梦建表时如果没加引号实际存的是大写。两边对不上。解决在props.dm里确认达梦的兼容模式或者在连接串加?compatibleModeoracle让达梦按 Oracle 的大小写规则处理。更稳妥的做法是检查sql.dameng/下的建表脚本确认表名统一加了双引号或统一大写。5.2 加载数据到一半卡死现象runDatabaseBuild.sh加载到某个仓库后长时间无输出也不报错。原因达梦的 redo 日志或表空间满了事务在等空间。也可能是磁盘 IO 被打满。解决另开一个会话查达梦的V$TABLESPACE看剩余空间查V$SESSION看有没有长时间等待的会话。如果是表空间问题扩表空间后重新跑如果是 IO 问题把数据文件放到更快的盘上。5.3 tpmC 低得离谱只有几百现象跑完发现tpmC只有几百远低于预期。原因大概率是terminals设得太小或者warehouses太小导致数据全在内存里没有真正压到磁盘。也可能是 JDBC 驱动版本不匹配走了低效的通信路径。解决先把warehouses调到 50 以上terminals调到 CPU 核数的 2 倍再跑一次。如果还是低换达梦官方推荐的 JDBC 驱动版本并在连接串里加上批量提交相关的参数。5.4 脚本报 “Permission denied”现象./runDatabaseBuild.sh提示没有执行权限。原因从 Windows 解压出来的文件丢了可执行位。解决chmod x run/*.sh一次性给所有脚本加执行权限。这个坑在 Linux 上解压 Windows 打的 zip 时几乎必现。5.5 测试结果波动大两次跑差一倍现象同样的参数两次跑出来的tpmC差很多。原因达梦的后台任务检查点、归档在测试期间触发抢了资源。或者测试机上有其他进程在跑。解决测试前把达梦的检查点间隔调长关闭不必要的后台任务。测试机上除了 BenchmarkSQL 和达梦不要跑别的重负载进程。正式测试前先空跑一次预热让数据进缓存再跑第二次取结果。6. 进阶用多轮阶梯压测摸清达梦的吞吐拐点单次跑分只能得到一个点真正有价值的是画出一条曲线。我的做法是固定warehouses50把terminals从 10 开始按 10、20、40、80、160 逐轮递增每轮跑 5 分钟记录tpmC和平均响应时间。当tpmC不再上升甚至下降而响应时间开始陡增时那个终端数就是这套达梦配置的吞吐拐点。具体操作上不用每次手改props.dm可以写个循环脚本#!/bin/bash # 阶梯压测固定仓库数递增终端数 for t in 10 20 40 80 160; do sed -i s/^terminals.*/terminals$t/ props.dm echo terminals$t ./runBenchmark.sh props.dm 21 | grep -E Measured tpmC|Measured tpmTOTAL sleep 30 # 让数据库喘口气避免上一轮残留影响下一轮 donesed那行是原地替换terminals的值grep只抓关键指标sleep 30是给达梦留出清理会话和刷脏页的时间。跑完把结果整理成表横轴终端数、纵轴 tpmC拐点一目了然。terminalstpmC平均响应时间(ms)观察10基准值低未压满20上升略升线性区40接近峰值明显升接近拐点80持平或微降陡增拐点已过160下降很高锁竞争严重这张表填满之后你就能拿着它去回答“达梦这套配置到底能扛多少并发”这个问题比任何单点数字都有说服力。还有一点每次改完props.dm记得确认dbdm没被误改我有一次sed替换时手滑把db那行也匹配上了结果跑了一轮 PostgreSQL 的脚本报了一堆看不懂的错排查了半天才发现是配置被改坏了。从那以后我每次跑阶梯压测前都强制先cat props.dm | grep -E ^db|^driver|^conn确认三行关键配置没被动过。希望这套流程能帮到你少走点我踩过的弯路。本文还有配套的精品资源点击获取