简介一份面向达梦数据库标准性能评测的BenchmarkSQL 5.0工具包适合数据库管理员、性能测试人员及架构师在数据库选型、容量规划与压测对比时使用。压缩包共94个文件、大小仅3.77MB内含19个class类文件、12个SQL场景脚本、11个Java源文件、9个JAR依赖包、8个Shell运行脚本、properties/XML配置以及R语言绘图脚本覆盖环境配置、数据装载、压测执行、结果生成完整链路目录安排清晰便于按需调整。已有799人浏览学习。该工具包特意集成达梦数据库连接配置与SQL脚本可通过修改props.dm快速对接达梦实例并运行TPC-C类基准负载包括线程数、仓库数和事务比例等参数均可自定义同时保留PostgreSQL、Oracle等主流数据库的适配文件能够横向比较不同数据库的性能表现。配套的generateReport.sh可自动汇总测试数据并生成图表附带的《联系作者.txt》和README文档则提供配置说明与常见问题指引是一套可直接落地的数据库基准测试解决方案。1. benchmarksql 数据库测试工具达梦数据库为什么值得专门适配一版把新部署的达梦数据库交到研发手里之前总得先有个让人信服的性能数字这时候 benchmarksql 数据库测试工具就是最常被提到的那个名字。它本质是一套开源的 TPC-C 基准测试实现原版默认面向 PostgreSQL、MySQL 这类库所谓“支持达梦数据库版”是有人把 JDBC 驱动、SQL 方言和 schema 映射改到能跑达梦。它的价值在于不用自己手写 5 类 TPC-C 事务不用自己造订单表数据跑完直接给出 tpmC 和响应时间。适合谁给达梦做上线前压测的 DBA、做国产数据库选型对比的架构师以及刚把达梦迁移完、想确认性能没掉链子的应用负责人。2. 先看懂 benchmarksql 的 TPC-C 模型四个写事务如何压出 tpmC跟随便发一轮并发 SELECT 不同benchmarksql 压的是完整交易模型。这一章把它的运行逻辑讲透后面配参数时你才知道每个数字在干嘛。2.1 TPC-C 不是压测协议是一套交易比例TPC-C 模拟的是一个商品批发商的订单系统里面有仓库、商品、库存、客户、订单这些实体。benchmarksql 把整个交易模型固定成了五类事务按固定比例随机分发事务标准占比在 benchmarksql 里的作用达梦适配关注点New Order45%新建订单涉及客户、库存、商品多表写入事务提交频率最高最吃日志写入Payment43%更新客户余额和仓库/地区统计主键更新并发容易暴露锁问题Order Status4%查询最近订单状态只读事务检查索引是否生效Delivery4%批量处理 10 个未发货订单一次更新多条观察批量提交表现Stock Level4%检查某个仓库库存水平聚合查询验证统计信息的准确性New Order 占了将近一半所以 benchmarksql 最终输出的核心指标叫 tpmCC 就是 New Order 事务含义是“每分钟成功提交的 New Order 事务数”。你在别处看到的 tpmTOTAL则是五类事务加起来的吞吐。这套比例是标准写死的不是工具作者拍脑袋定的。所以“达梦版”能被人接受前提是这些事务逻辑不能被改掉只能动数据库方言层。市面上流传的达梦适配版本本质上都是把 DDL、INSERT、UPDATE 的写法从 Postgres/Oracle 方言改成达梦能吃的语法事务比例和随机模型不动。记住这点你拿到任何一版都不容易被忽悠。2.2 build 与 run 两阶段先灌数据再压事务benchmarksql 跑一次完整测试分两个阶段对应两个脚本build 阶段runDatabaseBuild.sh建表、装数据。数据规模由配置里的 warehouses 参数决定每个 warehouse 模拟一个仓库的完整数据集。warehouses10 意味着有 10 个仓库的客户、商品、库存记录数据量大概在几百 MB 到 1GB 量级具体取决于页大小和压缩设置。run 阶段runBenchmark.sh启动 N 个终端terminals并发执行上面那五类事务跑固定分钟数最后汇总吞吐和响应时间。两个阶段必须分开因为 TPC-C 的规则是“先有一个确定的数据集再在这个数据集上跑业务”。如果你每次压测前都重新装载数据结果才有可比性拿一个已经跑了半小时、数据被改得面目全非的库再压第二轮数字会跟第一轮差很多这不是达梦的问题是所有 TPC-C 工具的通病。2.3 达梦版动了哪三处驱动、SQL 方言、schema 映射原版 benchmarksql 跑在 Postgres 上时连接走的是 org.postgresql.DriverURL 是 jdbc:postgresql://。要接达梦第一处就是换成达梦自己的驱动类 dm.jdbc.driver.DmDriver 和 jdbc:dm:// 协议。这步不做工具连数据库都登不进去。第二处是 SQL 方言。benchmarksql 建表、装载、事务里写了不少数据库特性语法原版跑 Postgres 会用到它的自增列和 RETURNING 子句跑 Oracle 分支会用到序列和 ROWNUM。达梦兼容 Oracle 语法所以常见的适配做法是以原版 Oracle 方言为基础把不兼容的分页、自增 ID、MERGE INTO 写法逐一改成达梦能执行的版本。这个工作量不大但很琐碎改错一处 build 阶段就会报错。第三处是 schema 映射。原版会单独创建一个 schema 来隔离测试数据而达梦的 schema 概念和用户绑定你登录谁默认 schema 就是谁。所以达梦版的配置里通常只需要指定一个专用用户建表和装载都发生在该用户下不再单独执行 CREATE SCHEMA。很多人在原版 props 基础上只换了驱动就去跑结果报“模式不存在”原因就在这里。3. 把达梦 JDBC 接进 benchmarksqlprops.dm 配置模板与 classpath 设置原理清楚后最实际的问题变成怎么让 benchmarksql 找到达梦驱动、连上库、按预期参数跑。这一章给出一份可以直接抄的 props.dm并逐行解释参数含义。3.1 达梦 JDBC 驱动与连接串5236 端口背后的那一套达梦数据库的 JDBC 驱动通常随安装包分发在安装目录下的 drivers/jdbc 目录里文件名类似 DmJdbcDriver.jar。包里的主类固定是 dm.jdbc.driver.DmDriver。端口默认 5236这也是你在 Navicat、IDEA 里新建达梦连接时填的那个端口跟 benchmarksql 里填的是同一套信息没有特殊开关。确认驱动包可用先在命令行看它里面有没有主类jar tf DmJdbcDriver.jar | grep DmDriver.class如果没安装 JDK 的 jar 命令也可以用压缩软件打开 jar 包直接找。看到 dm/jdbc/driver/DmDriver.class 就说明驱动包完整缺这一步后面所有报错都会指向同一个症状“找不到驱动”但原因可能是 jar 本身坏了。连接串格式是jdbc:dm://IP:端口默认端口 5236 可以省略但我建议写上因为如果达梦装的时候改过端口不写就回落到默认值容易被忽略。3.2 props.dm 参数逐行拆解仓库数、终端数、耗时与隔离级别原版 benchmarksql 用一个 properties 文件驱动达梦版沿用同样机制。下面这份是我常用的最小配置dbdm driverdm.jdbc.driver.DmDriver connjdbc:dm://127.0.0.1:5236 userbenchmarksql passwordbenchmarksql warehouses10 terminals20 loadWorkers8 runMins10 rampupMins3 runTxIsolationLevelTRANSACTION_READ_COMMITTED参数含义拆开说db、driver、conn、user、password这五项是连接基础。user 建议用专为测试建的用户不要拿 SYSDBA 跑因为 SYSDBA 的权限和普通用户不同压出来的锁行为没参考价值。warehouses仓库数。它决定 build 阶段的数据量也间接决定 tpmC 上限。10 个仓库属于入门验证级别想认真压一台 16 核机器至少 50 起步。terminals并发终端数。每个终端是一个独立数据库连接持续随机执行事务。这个值直接决定并发度调大看 CPU 能不能吃满调小看响应时间是否稳定。loadWorkers装载阶段并发线程数。只影响 build 数据的速度不影响压测结果。SSD 上可以设 8机械盘设 4 更稳。runMins正式压测分钟数。10 分钟只能算快速验证拿出去对标的测试我至少跑 30 分钟。rampupMins预热时间。这段时间内事务照跑但不计入统计。因为连接池初始化、缓存填充都发生在开头几分钟直接计入会把 tpmC 拉低。runTxIsolationLevel事务隔离级别。默认 READ_COMMITTED 符合 TPC-C 标准不要改成 SERIALIZABLE否则达梦的锁冲突会把结果压得很难看而且这不是数据库的问题是跑法错了。3.3 classpath 与驱动 jar 放置Navicat 能连不代表 benchmarksql 能连很多人在 Navicat 里连达梦一切正常换到 benchmarksql 就报 ClassNotFoundException原因只有一个驱动 jar 没进 Java 的 classpath。Navicat 自带驱动跟 Java 进程无关这个黑匣子最容易让人误判。最稳的做法是把 DmJdbcDriver.jar 拷到 benchmarksql 项目的 lib 目录下跟原版自带的 postgresql 驱动放一起cp 达梦安装目录/drivers/jdbc/DmJdbcDriver.jar benchmarksql/lib/ ls -l benchmarksql/lib/放置后再确认运行脚本能加载到它。benchmarksql 的 runDatabaseBuild.sh 和 runBenchmark.sh 内部会拼接 lib 目录下所有 jar 到 classpath所以只要 jar 在 lib 里理论上就够。但如果你改了脚本或者用 IDE 直接跑主类就得手动指定 classpath。另一个检查技巧先不跑全量测试写个 5 行的 Java 小程序验证连接。这一步能隔离出“配置问题”还是“网络问题”import java.sql.*; public class TestDm { public static void main(String[] args) throws Exception { Class.forName(dm.jdbc.driver.DmDriver); Connection conn DriverManager.getConnection( jdbc:dm://127.0.0.1:5236, benchmarksql, benchmarksql); System.out.println(conn.getMetaData().getDatabaseProductName()); conn.close(); } }编译运行时把 DmJdbcDriver.jar 放进 classpathjavac -cp lib/DmJdbcDriver.jar TestDm.java java -cp .:lib/DmJdbcDriver.jar TestDm如果这一小段能打印出数据库产品名说明驱动、连接串、账号权限都没问题接下来再折腾 benchmarksql 本身的配置才有意义。4. 跑通达梦版 benchmarksql 的三条命令从建库到看 tpmC配置写好后到真正出数字只有三步准备库、装载数据、跑压测。这一章把每一步的命令和判断标准写清楚。4.1 建测试库和专用用户一个 TABLESPACE 就够了用达梦自带命令行工具 disql 登录 SYSDBA创建一个表空间和专用用户。benchmarksql 的 build 脚本会自己建表不需要你手动执行任何 DDL。CREATE TABLESPACE tpcctbs DATAFILE /dm/data/tpcctbs.dbf SIZE 2048 AUTOEXTEND ON NEXT 512 MAXSIZE 32768; CREATE USER benchmarksql IDENTIFIED BY benchmarksql DEFAULT TABLESPACE tpcctbs; GRANT DBA TO benchmarksql;注意 DATAFILE 的路径必须真实存在否则达梦报文件路径错误Windows 装的话要写成反斜杠路径并且记得转义。GRANT DBA 这一步看着粗暴但对 TPC-C 测试是必要的build 阶段要大量建表、建索引普通权限会卡在权限不足上。建完用户后建议先做一次登录验证用新用户连一下disql benchmarksql/benchmarksql127.0.0.1:5236能进命令行就说明账号和端口没问题。另外如果达梦初始化实例时开了大小写敏感默认是开后续 build 阶段很可能踩表名找不到的坑这一节先在建实例时想好测试库建议初始化时把大小写敏感关掉或者全程使用大写建表。第 5 章会专门展开这个坑。4.2 ./runDatabaseBuild.sh 装载数据日志里看两类报错库准备好后执行装载cd benchmarksql ./runDatabaseBuild.sh props.dm这个脚本会读取 props.dm 里的 warehouses 数量建表、装商品、建索引最后打印类似 “Loading completed” 的结束标记。做得好一点的达梦版还会在结束时统计各表行数方便你核对。装载阶段最常见的两类报错SQL 语法错误说明这一版对达梦方言的适配不完整通常是某个建表语句里带了原版数据库的特殊关键字。定位方式是把日志里第一条报错 SQL 拿出来在 disql 里手工执行逐句修。主键或唯一约束冲突通常是因为重复跑过 build表里已有数据。先手工清理或重建用户再重跑不要试图在残留数据基础上覆盖。装载时长取决于 warehouses 和 loadWorkers。10 个仓库在普通 SSD 上几分钟内完成100 个仓库可能需要半小时以上。如果发现装载速度异常慢查看达梦的归档日志是否开启压测前把归档关掉能省很多时间测试库没必要开归档。4.3 ./runBenchmark.sh 压测结果表读法与 tpmC 口径装载完成进入正式压测./runBenchmark.sh props.dm脚本启动 terminals 个连接每个连接模拟一个终端按比例随机执行事务。压测期间控制台会周期性打印进度和实时吞吐让你确认没有连接断掉。结束后控制台输出一张汇总表核心字段长这样指标含义tpmTOTAL全部五类事务的每分钟吞吐tpmC仅 New Order 事务的每分钟吞吐TPC-C 的标准指标平均响应时间所有事务从发起到提交的均值90th/99th 响应时间长尾延迟观察抖动读数时记住对外汇报用 tpmC不要用 tpmTOTAL。tpmC 代表系统处理核心交易的能力tpmTOTAL 只是参考。如果你是拿达梦和别的数据库对比两边都必须跑同一套 benchmarksql 版本、同样的 warehouses 和 terminals否则数字没有意义。跑完后还要做一次逆向验证手工查一下达梦侧的事务提交数确认工具统计没丢数据。SELECT COUNT(*) FROM V$SESSIONS WHERE USERNAME BENCHMARKSQL;如果在压测期间这个查询能看到预期的终端数说明连接全部建立成功工具统计的数据才是可信的。这个验证动作很多人不做结果数字偏高却找不到原因其实是终端掉了几个没发现。5. 达梦适配版避坑指南驱动、大小写、模式与连接上限适配版 benchmarksql 跑达梦90% 的问题集中在五个地方。每一条都是我在实际跑批里见过的真实症状按“现象 → 原因 → 解决”写。5.1 ClassNotFoundException驱动 jar 不在 classpath现象执行 runDatabaseBuild.sh 或 runBenchmark.sh 开局就报java.lang.ClassNotFoundException: dm.jdbc.driver.DmDriver。原因两种情况。一是 DmJdbcDriver.jar 没有放进 lib 目录二是运行脚本被改过classpath 拼接逻辑没把 lib 里的 jar 带上。和数据库本身没有任何关系此时达梦服务是正常的Navicat 也连得上。解决把驱动 jar 复制进 lib 目录然后查看脚本里的 classpath 组装逻辑确认包含 lib 通配符。更稳妥的办法是用前面写的 TestDm.java 先验证 classpath 拼接后的效果再跑正式脚本。5.2 表或视图不存在大小写敏感建库的连锁反应现象build 阶段建表成功装载数据时报表或视图不存在而且报错的表名清一色是双引号包裹的小写。原因达梦建实例时默认大小写敏感CASE_SENSITIVE1。在这个模式下不带引号的标识符会被统一转成大写存储但 benchmarksql 的建表脚本里用了小写表名或者干脆没带引号。两边对不上执行时自然找不到表。这种问题在 Postgres 上不常见因为 Postgres 也是大小写敏感的但它的驱动会自动处理达梦版的适配往往没做这层转换。解决最省事的办法是建实例时把大小写敏感关掉CASE_SENSITIVE0测试库完全可以这么干如果实例已经建好改不了初始化参数就得手动把所有小写表名改成大写或者在 SQL 里给表名统一加双引号保原样。改完重新 build别在已有表上打补丁。5.3 模式不存在达梦的 schema 就是用户别跨用户建表现象连接和建表都正常但跑事务时报模式 BENCHMARKSQL 不存在或无效的模式名。原因达梦的 schema 跟登录用户绑定登录用户是 benchmarksql默认 schema 就是 BENCHMARKSQL。如果 build 阶段用 SYSDBA 建的表表落在了 SYSDBA 的 schema 下等 benchmarksql 用户登录跑事务时它去看自己的 schema自然什么都找不到。原版 benchmarksql 习惯单独 CREATE SCHEMA这个语义和 Oracle 系的达梦不一致。解决整个测试过程只用 benchmarksql 这一个用户完成建表、装载和压测不要混用账号。如果已经混了把残留表清理干净重新用 benchmarksql 登录跑 build。另外检查 props.dm 里的 user 是否和建表用户完全一致大小写也要对得上。5.4 压测中途连接被重置MAX_SESSIONS 与空闲回收现象压测跑了三五分钟控制台开始刷连接失败、connection resettpmC 断崖式下跌最后进程卡死。原因两个常见元凶。一是达梦实例的最大会话数MAX_SESSIONS小于 terminals 加其他业务连接数新连接直接进不来二是达梦的连接空闲超时设置太短benchmarksql 的终端在事务间隔期短暂空闲被服务端判定为僵尸连接杀掉。解决先用 V$SESSIONS 查询当前会话数和上限确认是不是触顶SELECT COUNT(*) FROM V$SESSIONS;如果数量压在 MAX_SESSIONS 附近调大 dm.ini 里的 MAX_SESSIONS 并重启实例。空闲超时问题则在达梦的 sqlnet.ora 或连接池配置里把空闲回收时间调长或者把 terminals 数降一档减少同时连接数。测试库上可以把这两个参数放得比较宽生产库不建议这样动。5.5 结果忽高忽低先看终端是否全部连上现象同一份配置昨天跑 tpmC 是 5 万今天跑变 2 万而且重跑几次都稳定在低位。控制台没有报错一切看着正常。原因terminals 对应的线程没有全部成功连接达梦。benchmarksql 默认对连接失败有重试逻辑重试期间该终端不产生事务但统计起点已经算上了它导致整体吞吐被稀释。更隐蔽的是连接池初始化失败但没打出明显错误只在你查 V$SESSIONS 时才发现少了几个。解决压测开始后立刻查一次会话数SELECT USERNAME, COUNT(*) FROM V$SESSIONS GROUP BY USERNAME;确认 benchmarksql 用户下的会话数等于 props 里的 terminals。不一致就去看达梦错误日志多半是连接数上限或密码策略问题。这个检查动作我已经养成习惯每次压测前 30 秒做一次能省掉后面几小时的排错时间。6. 让 tpmC 结果能对标终端比、rampup 与数据库基线三件事跑出一个数字很容易跑出一个能拿去对比的数字需要额外做三件事。第一固定 warehouse 和 terminal 的比例。常见做法是 1 个 warehouse 对应 45 个终端比如 50 warehouses 配 200250 个 terminals。不是越多越好终端太多而数据量小锁竞争会让结果失真数据量大而终端太少CPU 喂不饱tpmC 又偏低。对比测试时两台库用同一比例否则别看数字。第二rampup 至少 3 分钟正式运行至少 30 分钟。TPC-C 跑 10 分钟只能看个大概因为达梦的缓冲区、索引缓存都需要时间预热。超过 30 分钟后 tpmC 波动仍然超过 10%说明数据库参数或负载本身不稳定这时候报告结果是不负责任的。第三跑之前把达梦的基线参数存档。我一般会先查实例名、数据库版本、页大小、MAX_SESSIONS、归档是否开启连同 props.dm 一起放进结果目录。这样以后任何人质疑你这个 tpmC 是在什么环境下跑的你拿得出完整证据链。页大小这个参数尤其关键达梦建库时设了 8K 页和 32K 页跑 TPC-C 完全是两个表现不记录就等于没做测试。最后说一个我的个人习惯跑完压测不看 tpmC 排名先看报告里有没有失败事务。失败事务为零这个数字才有讨论基础有失败事务先排查原因再重跑。这个习惯帮我避过不少拿错数据交差的尴尬希望帮到你。本文还有配套的精品资源点击获取