简介
在过去一年半的时间里，在 标准TPC-C基准方面有很多DB2 for LUW 活动，这个基准常用于测试在线事务处理环境中的性能。其结果跨度很大，在具备通常配置的机器上，它可能是非常小的数字，在那些家庭和工作中不多见的特殊配置上，又可能是非常大的数字。
虽然填充数据库模式的行的数量可能被调整到一定规模，但有一个地方仍然是相同的：SQL。在本文中，您将认识 TPC-C 基准的逻辑，理解 SQL 技术，并发现如何在实际的客户环境中使用 SQL 技术。
为了达到这个目的，作者 Serge Rielau 这样来组织这篇文章：首先介绍该基准的 DB 模式以及它的事务。接着，他将分析每个事务，并解释每个事务的 SQL 特性。到本文的最后，您应该对 TPC-C 基准以及 DB2 的高级 SQL 特性，包括它们背后的机理有更好的理解。
TPC-C: 基准简述
TPC-C 基准使用一小组事务和表来模拟一家分销企业，该企业有一个产品销售周期。每个事务的外部模式和语义都被 正式指定。为了简短地概述一下，并提供一个基本模式以供使用，下面给出了一个概要。 其中，表用 粗体标记，事务用 斜体 显示：
用于该基准的数据库主要由仓库（warehouses）、地区（districts）、产品（items）和客户（customers）组成。在每个 WAREHOUSE 中的 STOCK（库存）里有 100,000 个 ITEM。每个仓库为 10 个 DISTRICT 服务。每个地区为 3000 名 CUSTOMER 服务，这些客户 ORDER（订购）新产品。 每份 ORDER（订单）最多可以由 15 种不同产品组成，称作 ORDER_LINE（订购项）。在给订单发货之前，订单作为一个 NEW_ORDER 进行排队，仓库中每种产品的库存要进行调整……在 DELIVERY（发货）时，要向客户收费。在 PAYMENT（支付）时，该事务被存档在 HISTORY（历史）中，收入要记帐。
此外，客户可以查问他们的 ORDER STATUS（订单状态），仓库管理员可以查问订单上所订产品的 STOCK LEVEL（库存水平）。
为了更切合实际，客户容易忘记他们的客户 ID，因此必须能够按用户的姓氏（last name）查找客户 ID，但客户的姓可能有重复现象。而且，本地的仓库可能无法满足所有的订单，这要求从远处的仓库发货过来。
一个仓库所能处理的新订单的数量限制在每分钟 9 到 12.86 个事务之间。这意味着，为了达到 320 万 TpmC （NEW ORDER Transactions per minute TPC-C），至少需要借助 256,000 多个仓库。这意味着有 77 亿 注册客户。因此，除非您有足够的磁盘和一个大的保险丝，否则不要试。