企业官网建设流程全解析

简介：这是一份面向数据库管理员、测试工程师与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之后，根目录下大致是这么几块东西，我按用途分一下：

关键就是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 ant

ant会读build.xml，把src/编译到build/，再打包到dist/。如果ant没装，用系统包管理器装一下即可。编译成功后会看到BUILD SUCCESSFUL。这一步的坑在于build.xml里可能写死了 JDK 路径，报错就打开build.xml看property name="javac.path"之类的配置，改成你本机的JAVA_HOME。

3. 配置 props.dm：连接串、仓库数与终端数的参数逻辑

3.1 props.dm 逐项拆解

props.dm是整个测试的控制中心，我把它最关键的几行拎出来讲：

db=dm driver=dm.jdbc.driver.DmDriver conn=jdbc:dm://127.0.0.1:5236/BMSQL user=bmsql password=Bmsql_123 warehouses=10 terminals=10 runMins=5 limitTxnsPerMin=0

• db=dm：告诉 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 分钟看稳定性。
• limitTxnsPerMin=0：不限速，让数据库跑满。设成非 0 会限制每分钟事务数，一般只在做阶梯压测时用。

3.2 连接串的几种写法与常见错误

达梦的连接串有几个变体，我列一下对比：

最常见的翻车是连接串里带了空格，或者密码里有特殊字符没转义。达梦密码如果含@、#这类字符，在 properties 文件里要小心，properties 不认转义，建议测试用户用纯字母数字加下划线的密码。

3.3 仓库数与终端数的搭配原则

这两个参数不是随便填的。仓库数决定数据规模，终端数决定并发压力。如果terminals远大于warehouses，会出现大量事务在等锁，TPS 反而上不去，这是典型的资源争用。经验比例是terminals不超过warehouses的 2 倍。比如 10 个仓库，终端最多设 20。反过来，仓库数很大但终端数很小，数据库根本压不满，测出来的 TPS 没有参考价值。

改完props.dm后，建议先跑一次小规模验证：warehouses=2、terminals=2、runMins=1，确认整条链路通了，再放大参数正式跑。

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 2>&1 | 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里确认达梦的兼容模式，或者在连接串加?compatibleMode=oracle让达梦按 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. 进阶：用多轮阶梯压测摸清达梦的吞吐拐点

单次跑分只能得到一个点，真正有价值的是画出一条曲线。我的做法是固定warehouses=50，把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 2>&1 | grep -E "Measured tpmC|Measured tpmTOTAL" sleep 30 # 让数据库喘口气，避免上一轮残留影响下一轮 done

sed那行是原地替换terminals的值，grep只抓关键指标，sleep 30是给达梦留出清理会话和刷脏页的时间。跑完把结果整理成表，横轴终端数、纵轴 tpmC，拐点一目了然。

这张表填满之后，你就能拿着它去回答“达梦这套配置到底能扛多少并发”这个问题，比任何单点数字都有说服力。还有一点，每次改完props.dm记得确认db=dm没被误改，我有一次sed替换时手滑把db那行也匹配上了，结果跑了一轮 PostgreSQL 的脚本，报了一堆看不懂的错，排查了半天才发现是配置被改坏了。从那以后我每次跑阶梯压测前，都强制先cat props.dm | grep -E "^db=|^driver=|^conn="确认三行关键配置没被动过。希望这套流程能帮到你，少走点我踩过的弯路。

本文还有配套的精品资源，点击获取