通过DB2 TPC-C基准实现探索SQL(2)

核心提示：清单 14. 用于支付事务的 SQL 语句1SELECT W_STREET_1, W_STREET_2, W_CITY, W_STATE,W_ZIP2, D_STREET_1, D_STREET_2, D_CITY, D_STATE, D_ZIP3, C_ID, C_FIRST, C_MIDDLE, C_STREET_

清单 14. 用于支付事务的 SQL 语句

1
SELECT　 W_STREET_1, W_STREET_2, W_CITY, W_STATE,　W_ZIP
2　　　　, D_STREET_1, D_STREET_2, D_CITY, D_STATE, D_ZIP
3　　　　, C_ID, C_FIRST, C_MIDDLE, C_STREET_1, C_STREET_2
4　　　　, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM
5　　　　, C_DISCOUNT, C_BALANCE, C_DATA　
6
INTO　 :w_street_1 , :w_street_2 , :w_city , :w_state , :w_zip
7　　　　, :d_street_1 , :d_street_2 , :d_city , :d_state , :d_zip
8　　　　, :c_id , :c_first , :c_middle ,　 :c_street_1 , :c_street_2 , :c_city , :c_state
9　　　　, :c_zip , :c_phone , :c_since , :c_credit , :c_credit_liM
10　　　　, :c_discount , :c_balance, :c_data :c_data_indicator
11
FROM TABLE ( PAY_C_LAST(　 :w_id
12　　　　　　　　　　　　　　, :d_id
13　　　　　　　　　　　　　　, :c_w_id
14　　　　　　　　　　　　　　, :c_d_id
15　　　　　　　　　　　　　　, :c_last_inpuT
16　　　　　　　　　　　　　　, :h_date
17　　　　　　　　　　　　　　, :h_amounT
18　　　　　　　　　　　　　　, :c_data_prefix_c_lasT
19　　　　　　　　　　　　　)
20　　　　　　　 )
AS PAY_C_LAST
21
WITH RR USE AND KEEP UPDATE LOCKS

在通常的优化的基础上，还应注意两种新的技术：

为了确定正确的客户，需要读 CUSTOMER 表。只有在此基础上，才可以执行对 CUSTOMER 表的更新。默认情况下，这意味着所有姓氏有问题的客户行将获得一个 共享锁（share lock）。为执行更新，需要将共享锁转换为一个 更新锁（update lock）。这里有一个小小的风险，同一个客户可能想要在同一时间为另一个订单进行支付。如果是在取数据（fetch）和更新（update）之间发生这样的情况，那么就会出现 死锁（dead lock），因为如果另一个事务持有共享锁的话，这两个事务就都不能获得更新锁。为了避免这样情况发生，DB2 V8.2 支持所谓的 lock-request-clause。在这个例子中， WITH RR USE AND KEEP UPDATE LOCKS 将导致 DB2 在整个语句中收集最少的更新锁，而不是共享锁。为了语义上的纯净和未来的可扩展性，这个 SQL 函数使用一个匹配子句 INHERIT ISOLATION LEVEL WITH LOCK REQUEST。

为了发现中间的客户，这里选择了使用 ROW_NUMBER()。这个 OLAP 函数将所有同姓的客户按照他们的名字来编号。而且，这里决定不使用一个单独的查询来获得总的 COUNT。相反，这里再次使用 OLAP。这需要在用于缓冲所有匹配客户的内存消耗 —— 因为总 COUNT 必须跟在每个客户的后面，但是这个总 COUNT 只有到最后才知道 —— 和从客户表进行两次索引扫描之间作出取舍。对于行数较少并且每行的宽度不大的情况，实际上使用 COUNT(*) OVER() 的 (C_ID, COUNT, NUM) 要好一些。

清单 15 展示了支付事务的计划。

清单 15. 支付事务的访问计划