Swingbench SQLBuilder实战：自定义SQL压测与绑定变量配置指南

先说一个现象。很多人把Swingbench拿过来，第一件事就是双击Order Entry，跑一圈看个曲线，然后得出结论“数据库性能还不错”。这个流程本身没问题，问题是Order Entry只是Swingbench内置的样例负载，它的SQL形态是固定的，和你生产环境里的真实业务SQL基本差着十万八千里。你拿它验证“数据库能不能扛住”可以，但你拿它验证“我们这套业务跑上去会不会出事”，结论基本不靠谱。

这就是SQLBuilder存在的意义。它是Swingbench里一个容易被忽略但作用极大的功能模块，允许你在不写Java代码、不改Swingbench源码的前提下，把自定义的SQL脚本挂到压测框架里，用真实的表结构、真实的绑定变量、真实的业务比例去压测。这篇文章我会从SQLBuilder的实际操作链路、脚本内部结构和自定义压测SQL的完整落地过程展开，最后聊一聊我跑自定义脚本时踩过的几个坑。内容基于Swingbench常见的稳定版本实践，适合DBA、性能测试工程师、以及正在做数据库选型和容量评估的架构师参考。

1. Swingbench里为什么需要SQLBuilder：默认脚本的局限与这块功能的真正作用

先说清楚一个问题：Swingbench自带的Order Entry、Sales History这些场景，它们到底是什么水平。Order Entry模拟的是一个典型的OLTP系统，有客户、商品、订单、订单明细四类核心表，SQL以主键点查、短事务插入、小范围更新为主。从压测框架角度看，它是合格的，因为它能产生足够多的逻辑读和事务量；但从业务模拟角度看，它非常“理想化”——真实系统的SQL写得再规整，也不可能全部都是主键点查。

我见过太多团队用Order Entry压测后得出“数据库负载很低”的结论，实际上换一套业务SQL上去，数据库立刻出现大量硬解析、行锁等待或者全表扫描。原因很简单：Order Entry里没有复杂的多表关联，没有大批量查询，没有特殊类型绑定变量，也没有对时间列、状态列这类倾斜分布字段的访问。你压完之后，只能说“这台机器跑Order Entry没问题”，不能说明你真实的业务没问题。

SQLBuilder恰恰是用来弥补这个鸿沟的。它允许你把自己业务里的核心SQL语句，通过一个可视化的配置界面和一个XML脚本描述文件，注入到Swingbench的用户模拟线程中。每个SQL可以设置权重，可以定义绑定变量的生成规则，可以决定在每次事务循环中被执行的频率。这样一来，压测就不再是Swingbench自说自话，而是你真实业务的近似回放。

需要特别说清楚的是，SQLBuilder不是让你把整条复杂SQL直接粘贴进去就完事的工具。它会把你写的SQL挂在一个模拟用户（线程）的循环事务里，用绑定变量模拟每次调用时参数的变化。所以它的适用场景是：

• 你有明确的SQL清单，想验证数据库在当前数据量、当前硬件下的响应时间和吞吐量；
• 你想模拟真实OLTP读写比例，验证行锁、热点块、并发更新等场景；
• 你想对比不同参数配置（比如SGA大小、优化器模式、索引设计）对业务SQL的影响；
• 你想在压测环境里提前暴露慢SQL和糟糕执行计划，而不是等上线后再处理。

从定位上讲，SQLBuilder相当于给了你一个“SQL脚本执行器+并发调度器+性能采集器”的组合体。它不会替你分析SQL好不好，但它能按照你设定的比例和频率，把这些SQL压向数据库，并告诉你每一条SQL花了多久、消耗了多少资源。想要用好它，第一步就是搞清楚它生成的脚本文件是怎么组织的。

2. SQLBuilder的完整操作链路：从启动入口到脚本生成

2.1 打开SQLBuilder的正确方式

Swingbench安装完后，主目录下会有bin文件夹，里面有多个启动脚本。平时大家用的是swingbench（图形主界面），而SQLBuilder实际上是Swingbench主界面里的一个功能页签，在左侧栏选择你加载的压测基准后，会有一个“SQL Builder”入口。常见版本里，你可以通过主界面的Tools菜单或者基准配置界面里的Scripts选项进入。

很多人第一次进去会觉得空空荡荡，因为SQLBuilder默认不会自动加载任何SQL——它需要你显式地创建一个新的脚本集，或者加载一个已有的XML配置文件。这里有个习惯建议：动手之前先规划好自己的SQL清单，编号、分类、注释都写好，然后再开始创建。我一开始就是随手建、随手改，最后脚本集里堆了二十多条SQL，权重也乱，跑了半天数据根本没法分析。

进入SQLBuilder之后，你会看到左侧是脚本列表，右侧是SQL编辑区和参数配置区。新建一个脚本集后，它会在你指定的Swingbench基准目录下生成对应的XML文件和SQL脚本文件。如果是在原有基准上做修改，注意先备份原目录，因为一旦保存并运行，SQLBuilder会以新的脚本集覆盖默认的SQL定义。

2.2 手工添加一条SQL：从编辑到参数绑定的完整流程

SQLBuilder的操作逻辑非常直白，它就是围绕“SQL文本”和“绑定参数”这两个核心对象组织的。我以一条很常见的业务SQL为例：

sql复制SELECT o.order_id, o.order_amount, c.customer_name
FROM orders o, customers c
WHERE o.customer_id = c.customer_id
AND o.order_date >= :start_date
AND o.order_status = :status

这条SQL有两个绑定变量，:start_date 和 :status。在SQLBuilder中，你只需要把SQL文本粘贴进编辑区，然后在参数区分别为这两个变量定义生成规则。

• :start_date 可以定义为日期范围随机生成，模拟“最近30天内的某个时间点”；
• :status 可以定义为枚举值随机，从 COMPLETED、PENDING、CANCELLED 中按权重选择。

生成规则的配置粒度很细，支持随机整数、随机字符串、固定值、序列递增、日期区间、枚举值等多种模式。这一步是SQLBuilder的核心价值所在——它让每条SQL每次执行时的参数都不同，从而模拟出真实业务的参数漂移，而不是拿同一个绑定变量值反复怼数据库。

配置完成之后，记得设置权重（Weight）。权重决定了这条SQL在事务循环里被执行的相对频率。比如订单查询执行100次，订单插入执行50次，那么查询权重给10、插入给5，跑出来的效果就接近这个比例。

2.3 保存、编译与脚本集的目录结构

当你保存SQLBuilder配置后，会在基准目录下生成一组文件。以常见的标准组件为例，你会看到：

• sqlconfig.xml：核心配置文件，保存了脚本集里所有SQL定义、绑定变量、权重；
• sqlscripts/ 目录：存放实际的SQL脚本文件，每个SQL一条或多条语句；
• gatherstats.sql、dataload.sql 这类辅助脚本：分别用于收集统计信息和生成测试数据，会在压测准备阶段用到。

之所以拆成多个文件，是因为Swingbench的框架需要一个统一的加载入口（XML），但SQL本身以独立文件保存会更方便版本管理。你完全可以用Git管理这些SQL脚本，压测前打上标签，这样每次压测对应的脚本版本都可追溯，这对后续分析结果、复现问题非常有帮助。

提示：如果你修改了XML或SQL脚本，不需要重启Swingbench，只需在连接压测前重新加载基准配置即可。但如果SQL脚本文件里保存的是多语句块，SQLBuilder对事务边界的处理是：同一SQL脚本内的多条语句默认在一个事务里执行。要模拟独立事务，请把每条语句拆成单独的SQL条目，并按实际业务比例设置权重。

完成这一步，你的自定义脚本就具备运行条件了。但先别急着开跑，脚本的结构直接决定压测质量，下一节我拆开讲一下里面的设计逻辑。

3. 生成的脚本到底长什么样：XML配置、SQL文件与权重设计的内部逻辑

3.1 一份SQLBuilder XML配置的典型结构

为了让你对SQLBuilder生成的东西有直观认识，我贴一份简化过的XML结构（不同版本节点名略有差异，但核心逻辑一致）：

xml复制<?xml version="1.0" encoding="UTF-8"?>
<sqlconfig>
  <connection type="shared" minconn="5" maxconn="200" />
  <sqlscripts>
    <sqlscript name="OrderQuery" description="查询订单头" weight="10">
      <source>sqlscripts/order_query.sql</source>
      <bindvars>
        <bindvar name="start_date" type="date" min="2024-01-01" max="2024-12-31" format="yyyy-MM-dd" />
        <bindvar name="status" type="enum">COMPLETED|PENDING|CANCELLED</bindvar>
      </bindvars>
    </sqlscript>
    <sqlscript name="OrderInsert" description="创建订单" weight="5">
      <source>sqlscripts/order_insert.sql</source>
      <bindvars>
        <bindvar name="customer_id" type="random" min="1" max="1000000" />
        <bindvar name="order_amount" type="randomfloat" min="10" max="5000" precision="2" />
      </bindvars>
    </sqlscript>
  </sqlscripts>
</sqlconfig>

注意几个关键点。

第一，每个<sqlscript>节点定义了一条可独立调度的SQL或事务，name 是它在你压测报告里的标识，description 是可读说明，weight 是它在这个脚本集里的权重。

第二，<source>指向的SQL文件存放实际要执行的语句，SQL文件里仍然使用:name形式的绑定变量占位符。

第三，<bindvars>区里的每一个<bindvar>对应SQL文件中的一个绑定变量。类型很丰富，date、random、randomfloat、enum、sequence、list等都有。SQLBuilder在每次执行前会按照这个配置生成一个新的参数值，然后绑定进SQL里执行。

这个XML结构最大的好处就是可维护。你要调整SQL比例，改一下weight就行；要调整数据范围，改一下min/max就行；要增加一条SQL，复制一个<sqlscript>节点，改一下source和bindvars就行。整个过程不需要重新编译任何代码，保存后重跑压测即可。

3.2 权重设计：不是简单的“次数比”

很多人理解weight就是“执行次数比”，这没错，但不够准确。Swingbench的线程调度模型是：每个虚拟用户线程在事务循环内，按权重概率选择一条SQL脚本来执行。也就是说，weight决定的是概率分布，而不是固定次数。假设你配置了A、B两条SQL，权重分别是10和20，那么一次循环里，A被选中的概率约等于三分之一，B约等于三分之二。

这个机制意味着，权重设置的合理性直接决定压测负载是否贴近真实业务。我举个例子：某个系统读SQL非常多，写SQL很少，但如果你的SQL清单里只放了查询和插入两条SQL，而且权重配成1:1，跑出来数据库的redo量、锁等待分布会和你生产的实际情况差得很远，这样的压测结果参考意义有限。

因此我建议，在配置SQLBuilder脚本集时，先统计生产环境AWR或v$sql里的SQL执行次数TOP N，把TOP N映射到你的压测SQL清单里，再按真实执行次数的比例设置权重。比如你生产环境里的订单查询每秒执行2000次，而订单插入每秒执行200次，那么权重配10:1，这样压测出来的负载比例才接近真实。

3.3 绑定变量类型与生成规则的选择

绑定变量的配置是SQLBuilder里最值得花时间研究的细节，因为它直接决定SQL执行计划的稳定性。生产环境里最常见的SQL性能问题就是绑定变量类型、长度与表结构不匹配，导致优化器选择错误的执行计划。

我见过一个典型案例：某条SQL的过滤条件是ORDER_DATE = :V1，表里ORDER_DATE是DATE类型，但SQLBuilder里把绑定变量类型配成了randomdate，生成的日期格式带有时分秒。在实际执行时，优化器为了匹配字符串和日期，可能会对列做隐式转换，导致索引失效，出现全表扫描。压测一跑起来，数据库CPU直接飙高，但业务SQL本身其实没问题。

所以在配置绑定变量时，务必按下面几个原则来：

• 类型必须与表中字段类型一致。字段是NUMBER，绑定变量就用整数或浮点类型；字段是DATE，就选日期类型，并注意格式；
• 取值范围要与实际数据分布匹配。如果表里只有最近三个月的数据，而你把日期范围配成过去十年，那大量查询都会扫不到数据，逻辑读很低，压测结果会假性偏优；
• 对枚举类型的状态字段，不要平均配比。比如订单状态90%是COMPLETED，5%是PENDING，5%是CANCELLED，那么枚举的权重也要按这个比例配，否则会扭曲热点数据块的访问分布。

把这三条原则吃透，你的SQLBuilder脚本集才算真正具备模拟能力，而不是仅仅把SQL跑出来。

4. 一个从0到1的自定义压测实例：以ERP订单场景为例

讲完原理和文件结构，接下来我用一个完整的实例，把从建表到压测跑通的整个过程串起来。这个例子的业务背景是一个简化版ERP系统的订单模块，核心操作有客户查询、订单创建、订单状态更新、日报聚合。我会按照实际操作顺序一步一步来，你可以直接照着复现。

4.1 场景建模与SQL清单准备

压测前的第一步永远是梳理SQL清单，而不是直接打开工具。我根据业务经验，把压测目标设计成4条核心SQL：

• SQL-1：按客户编号查询客户信息，主键点查，主表访问；
• SQL-2：插入一条订单记录，模拟新增订单；
• SQL-3：按订单编号更新订单状态，模拟订单流转；
• SQL-4：按日期统计当日订单金额和数量，模拟报表查询。

这4条SQL覆盖了点查、插入、更新、聚合四类最常见的OLTP操作，同时也对应了索引扫描、redo生成、行锁等待、聚合扫描这几类典型的资源消耗模式。

对应的真实SQL文本如下：

sql复制-- SQL-1 customer_query
SELECT customer_id, customer_name, customer_level, phone
FROM customers
WHERE customer_id = :cid;

-- SQL-2 order_insert
INSERT INTO orders(order_id, customer_id, order_date, order_status, order_amount)
VALUES (:oid, :cid, SYSDATE, :status, :amount);

-- SQL-3 order_update
UPDATE orders SET order_status = :new_status, update_time = SYSDATE
WHERE order_id = :oid;

-- SQL-4 daily_report
SELECT order_date, COUNT(*) AS order_cnt, SUM(order_amount) AS sum_amount
FROM orders
WHERE order_date >= TRUNC(SYSDATE) - :delta_days
GROUP BY order_date;

4.2 建表与数据准备：这一步决定了压测有没有参考价值

SQL的宿主表必须建好，并且要有和真实环境接近的数据量。在这个例子里，我建两张表：customers 和 orders，数据量和索引结构如下：

sql复制CREATE TABLE customers (
    customer_id     NUMBER(10) PRIMARY KEY,
    customer_name   VARCHAR2(64),
    customer_level  VARCHAR2(16),
    phone           VARCHAR2(20)
);

CREATE TABLE orders (
    order_id        NUMBER(10) PRIMARY KEY,
    customer_id     NUMBER(10) NOT NULL,
    order_date      DATE NOT NULL,
    order_status    VARCHAR2(16),
    order_amount    NUMBER(10,2),
    update_time     DATE
);

CREATE INDEX idx_orders_customer ON orders(customer_id);
CREATE INDEX idx_orders_date ON orders(order_date);

我准备压100万客户、1000万订单数据。如果手动插入，太慢，所以用Swingbench自带的数据生成能力——它支持基于表结构的批量数据加载。数据量级上有一个经验原则：数据量至少要压到真实环境核心表数据量的50%以上，否则索引扫描、聚合计算的开销会失真。你有真实生产数据导入那最好，如果没有，就用生成工具按分布规则填充。

数据生成完成后，记得收集统计信息，这一步很多人会漏掉：

sql复制BEGIN
  DBMS_STATS.GATHER_TABLE_STATS(USER, 'CUSTOMERS');
  DBMS_STATS.GATHER_TABLE_STATS(USER, 'ORDERS');
END;
/

统计信息一旦缺失或过期，优化器可能给SQL-4这种聚合查询选择错误的执行计划，压测结果就完全没有参考意义了。

4.3 在SQLBuilder里配置这4条SQL

按前面说的操作流程，在SQLBuilder里新建脚本集，把4条SQL依次加进去，配置各自的绑定变量生成规则。这里我重点说明几条关键配置：

SQL-1（客户查询）——绑定变量cid使用随机整数范围1到1000000，对应客户表主键分布。权重设为30，模拟高频查询。

SQL-2（插入订单）——绑定变量oid使用序列递增，避免主键冲突；cid同上随机；status用枚举，COMPLETED和PENDING按9:1分配；amount用浮点随机，范围10到5000。权重设为10。

SQL-3（更新订单）——绑定变量oid用随机整数1到10000000；new_status用枚举，值从PENDING到COMPLETED、CANCELLED。权重设为15。

SQL-4（日报聚合）——绑定变量delta_days用枚举，1到7；权重设为5，模拟低频聚合查询。

配置完后，保存并重新加载基准配置。在Swingbench连接压测前，确认脚本集里4条SQL都在，并且权重比例是30:10:15:5，大致模拟了“读多、写少、更新居中、聚合低频”的真实业务形态。

4.4 跑压测时的参数设置与监控建议

启动压测时，有几个参数会直接影响自定义脚本集的执行效果。

用户数（并发线程数）建议从50开始，逐步增加到100、200、500，观察数据库的CPU、IO和等待事件变化，找到拐点。-d 指定压测时长，建议单轮至少跑15分钟以上，前2分钟数据需要丢弃，因为连接建立、buffer cache预热和数据分布都会在前面几分钟产生异常毛刺。

我自己用的命令行示例大概长这样：

bash复制./swingbench -c configs/erp_order_bench.xml \
  -u soe -p soe -cs localhost:1521/ORCLPDB1 \
  -uc 100 -d 600 -o results/erp_run1.csv

-c 指定自定义基准配置文件，-u/-p 是测试用户，-cs 是连接串，-uc 是用户数，-d 是持续时间（秒），-o 是输出结果文件。

压测过程中建议持续监控两个层面：数据库层，看看v\$session里有没有大量enq: TX - row lock contention、cursor: pin S wait on X等待；OS层，看CPU的user/sys比例、磁盘IO的await。一旦发现某个等待事件明显偏高，说明你自定义的SQL组合已经触发了某个瓶颈，这个时候的压测价值反而最大。

5. 结果解读、典型翻车现场与调优方向

5.1 怎么读懂Swingbench输出的关键指标

跑完一轮，Swingbench会生成CSV结果文件和图表。指标很多，但核心就几个：每秒事务数（Transactions/sec）、每秒净收益（NPS，Net Profit per Second，相当于有效业务吞吐量）、平均响应时间、CPU使用率、物理读/逻辑读、redo生成速率。

我一般先看NPS和平均响应时间的乘积趋势。如果NPS很高，但平均响应时间一直在涨，说明系统已经进入了饱和区，后端等待在累积；如果NPS曲线平稳、响应时间平稳，说明负载还没有把系统压垮。

对于SQLBuilder自定义脚本的场景，还要额外关注“每条SQL的响应时间拆分”。Swingbench的报表里可以按脚本名（也就是你XML里每条SQL的name）查看平均响应时间、执行次数、失败次数。如果你的业务SQL清单里某条SQL耗时特别高，说明这条SQL本身在压测环境下有性能问题，需要回到执行计划层面排查。

5.2 三个我真实踩过的坑

先说说最常遇到的坑：绑定变量类型不匹配导致执行计划漂移。我有一回模拟日期过滤SQL，在SQLBuilder里把日期绑定变量配成了字符串类型，跑出来的AWR里出现了大量INTERNAL_FUNCTION转换，索引都没用上。折腾了很久，最后发现是配置问题，不是数据库问题。这就是我前面强调“类型必须一致”的原因。

第二个坑是权重配置严重失真导致的误判。有次为了验证一个更新热点问题，我把更新SQL的权重调得特别高，结果压测放大了一个本来在生产环境不算严重的行锁争用，差点让团队误判了系统容量。后来我意识到，权重必须依据生产环境的真实执行频次来配，而不是凭感觉调。

第三个坑是数据分布没做索引列对齐。我把订单表按ORDER_DATE区间灌数据，但SQL-4的查询大量使用TRUNC(SYSDATE) - :delta_days来扫描最近N天数据，如果灌数据时日期没有集中在最近一段区间，那么查询扫出来的数据量会和预期完全不同，压力就失真了。

5.3 进阶调优思路：从自定义脚本回归到真实业务负载

当你熟悉了SQLBuilder的基本用法后，可以往更深一层走：把脚本集从“业务SQL清单”升级为“业务负载模型”。也就是说，不只是按比例执行几条SQL，还要考虑事务的依赖关系、不同时段的并发强度、批量任务的穿插等等。

比如ERP场景里，月末结账时的日报聚合SQL会大面积扫描历史数据，和日常OLTP的点查完全不一样。你可以在SQLBuilder里配置一个单独的“月末批量”脚本集，把这些聚合SQL串进去，权重按批量窗口时长折算。这样一来，你就能模拟一天里不同时段的负载差异，压测覆盖度会高很多。

还有一点，如果你们公司维护了生产环境的TOP SQL采集脚本，完全可以做一次自动转换：把TOP SQL标准化格式化成SQLBuilder的XML配置，权重直接从执行次数换算。我第一次这么做之后，压测结果和生产事故的重合度明显提高，这也是SQLBuilder这个功能带给我最大的价值。

最后分享一个小技巧。SQLBuilder生成的XML和sqlscripts目录一定要和压测基准版本一起纳入版本管理。每次改脚本、调权重、换表结构，都打个标签。这样压测出问题时，你能精确回到某一个版本的脚本集去复现，而不会出现“我记得当时跑的不是这个结果”的尴尬情况。跑压测这件事，最怕的就是不可复现，而SQLBuilder的脚本化设计恰恰给了你可复现的抓手。