基准测试 TPC-C 标准
什么是 TPC‑C 基准测试
TPC‑C 是由事务处理性能委员会（Transaction Processing Performance Council，简称 TPC）制定的联机事务处理（OLTP）基准测试标准。它模拟了一个典型的批发供应商业务环境，用于评估数据库系统在处理高并发、大规模并发事务时的性能表现。与单纯测试硬件峰值指标的基准不同，TPC‑C 同时考察数据库设计、事务逻辑、锁机制、I/O 调度等全栈能力，是目前公认最严苛、最具公信力的 OLTP 测试标准之一。
核心业务模型
TPC‑C 虚构了一个拥有多个仓库、多个销售区域和终端客户的批发公司，其核心业务由 5 种事务组成，覆盖完整订单生命周期。
仓库‑区域‑客户三层结构
- 仓库（Warehouse）：每个仓库服务 10 个销售区域
- 区域（District）：每个区域拥有 3000 个客户
- 客户（Customer）：是订单和支付操作的最小粒度
比例固定为 W∶D∶C = 1∶10∶3000，测试时通过扩展 W（仓库数）来线性增加数据量和并发压力。
5 种核心事务
| 事务类型 | 缩写 | 描述 | 占比（最低要求） |
|---|---|---|---|
| 新订单 | New‑Order | 录入一个新的客户订单，包含若干订单行，并立即扣减库存 | ≥ 43% |
| 支付 | Payment | 客户支付订单，更新客户余额、区域和仓库的总销售额 | ≥ 43% |
| 订单状态查询 | Order‑Status | 查询指定客户最近一笔订单的详情 | ≥ 4% |
| 发货 | Delivery | 批量处理未发货订单，更新订单状态并累加客户余额 | ≥ 4% |
| 库存水平查询 | Stock‑Level | 统计某一区域内库存低于阈值的商品数量 | ≥ 4% |
理解要点：New‑Order 和 Payment 合计至少占 86%，这反映了真实 OLTP 场景中“写密集、读写混合”的压力比例。所有事务必须满足严格的响应时间约束，Transaction‑RATE 才被认可。
主要指标与度量
TPC‑C 不单纯比拼峰值速度，而是通过复合指标反映系统的“性能‑价格‑一致”三维能力。
tpmC（每分钟新订单事务数）
- 定义：系统在一分钟内能够完成的 New‑Order 事务的数量。
- 这是 TPC‑C 官方最核心的性能指标，所有公开排名均使用 tpmC 作为排序依据。
- 计算方式：记录整个稳态测试期间完成的 New‑Order 事务总数，除以测试时长（分钟），并剔除不满足响应时间要求的事务。
响应时间约束
每个事务必须满足 第 90 百分位响应时间 ≤ 规定阈值 的要求，否则该事务不计入有效吞吐。
| 事务类型 | 响应时间限制（秒） |
|---|---|
| New‑Order | ≤ 5 |
| Payment | ≤ 5 |
| Order‑Status | ≤ 5 |
| Delivery（交互式） | ≤ 5 |
| Stock‑Level | ≤ 20 |
这种硬约束防止系统通过“牺牲单个事务延迟”来虚高吞吐，从而保证结果与用户体验相关。
价格/性能比（$/tpmC）
- 反映单位性能所需的硬件、软件、维护总成本。
- 包括 3 年总拥有成本（硬件、软件、维护）除以 tpmC，鼓励高性价比方案。
可审计性与合规要求
任何声称“符合 TPC‑C”的结果必须提交完整审计报告，包含：
- 详细的系统配置、硬件清单
- 可复现的脚本与参数
- 第三方审计机构的认证标识 只有经过审计的 TPC‑C 正式公布结果 才被认可，其余只能称为“类 TPC‑C”测试。
测试流程与阶段
正式 TPC‑C 测试包含多个严格阶段，确保结果可验证且反映稳态性能。
1. 数据库装载
- 按指定 W 值生成初始数据，必须使用 TPC 提供的数据生成工具。
- 数据装载后需要执行一系列的完整性检查（如基数校验、一致性检查）。
2. 预热与斜坡上升
- 系统逐步增加负载，直至达到目标并发数，然后保持运行一段时间。
- 该阶段的数据不计入最终成绩，但必须证明系统在进入稳态阶段之前已经稳定。
3. 稳态测量（至少 8 小时）
- 在规定的并发用户数下持续运行至少 8 小时（金融等严格场景要求更长）。
- 记录每间隔固定时间（如 1 秒）的各项事务完成数、响应时间、系统资源利用率等。
- 这是计算 tpmC 的唯一合法时间段，必须全程满足响应时间约束。
4. 斜坡下降与后处理
- 停止新事务后，确保所有进行中的事务正确提交或回滚。
- 再次执行数据一致性检查，证明测试后数据保持事务 ACID 特性。
初学者容易混淆的要点
仓库数量 ≠ 直接并发数
增加 W 会增大数据量，同时也必须按比例增加终端模拟用户数，但真正的并发压力取决于活跃用户数 x 事务率分布，而不是 W 本身。通常测试中活跃终端数约为 W × 10。
tpmC 是“有效吞吐”而非发送量
即使数据库每秒处理 100 万次请求，如果 New‑Order 的响应时间超出 5 秒，那些超时事务全部无效。很多“自测结果”很高，就是因为忽略了响应时间约束。
类 TPC‑C 与官方 TPC‑C 的区别
- 官方 TPC‑C 需要独立审计，测试环境必须公开，且公布的配置不能后续更改。
- 厂商自行宣称的“TPC‑C 可比”测试往往简化事务逻辑、放宽响应时间或修改数据访问模式，其结果不具备公信力。
如何使用 TPC‑C 进行实践学习
即使不追求官方认证，通过开源工具模拟 TPC‑C 也是理解数据库性能调优的高效手段。
推荐工具
- BenchmarkSQL：纯 Java 实现，支持多种数据库，配置简易，可生成接近 TPC‑C 的负载。
- Sysbench 的 oltp_read_write 模式：虽然不完全等于 TPC‑C，但逻辑相似，适合快速对比。
- HammerDB：图形化操作，内置 TPC‑C 方案，支持自动生成图表。
调整测试参数的常见方向
- 增加 W 值，观察存储引擎的缓存命中率变化
- 观察 New‑Order 的锁等 待情况，理解死锁检测与索引设计对其影响
- 监控 90 百分位响应时间，并与 tpmC 随并发增加的变化趋势对比，寻找性能拐点
分析输出举例
测试完成后，重点关注：
- 实际事务分布是否接近 45/43/4/4/4
- New‑Order 的 90th% 延迟是否远小于 5 秒
- 无效事务数量是否持续为 0
- CPU 与 I/O 等待时间在压测期间的占比
只有满足所有这些条件，自测的 tpmC 值才具有内部参考意义。
总结
TPC‑C 为 OLTP 系统提供了从业务逻辑、数据分布到性能度量的完整压力模型。理解它不仅是看懂数据库跑分的关键，更是工程师进行容量规划、参数调优和架构选型时的重要思维框架。即使只借助开源工具复现“类 TPC‑C”测试，也能快速暴露系统在高并发写场景下的真实瓶颈，远比单纯读写混合测试更有实战价值。