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

核心提示：清单 17. 调用函数1SELECT O_ID, O_CARRIER_ID, O_ENTRY_D, C_BALANCE, C_FIRST, C_MIDDLE, C_Id2INTO :o_id, :o_carrier_id , :o_entry_d , :c_balance, :c_first, :c_middle, :

清单 17. 调用函数

1
SELECT O_ID, O_CARRIER_ID, O_ENTRY_D, C_BALANCE, C_FIRST, C_MIDDLE, C_Id
2
INTO :o_id, :o_carrier_id , :o_entry_d , :c_balance, :c_first, :c_middle, :c_id
3
FROM TABLE ( ORD_C_LAST(　 :w_id
4　　　　　　　　　　　　　　, :d_id
5　　　　　　　　　　　　　　, :c_last_inpuT
6　　　　　　　　　　　　　)
7　　　　　　　)
AS ORD_C_LAST

清单 18. 用于订单状态查询的 SQL 语句

1
SELECT OL_I_ID, OL_SUPPLY_W_ID, OL_QUANTITY, OL_AMOUNT, OL_DELIVERY_d
2
FROM ORDER_LINE
3
WHERE OL_W_ID = :w_id
4
AND OL_D_ID = :d_id
5
AND OL_O_ID = :o_id
6
FOR FETCH ONLY ;

这里同样应用了很多常用的提高性能的技巧。例如，所有未涉及订购项的步骤都被封装到一个 SQL 表函数中。而且，这里使用 OLAP 来检索“中间客户”。然而，最后从这个查询中还可以收集到一些有趣的事情：

天真的人可能会首先确定客户的最大订单 id，然后使用这个 ID 来检索送货人和订单日期。如果订单 id 按照降序排序，则一个客户的最大订单 id 也就是基于客户 id 和订单 id 的索引中的第一个订单 ID。然而，利用这一事实将那两个查询组合到一起则显得更为紧凑。给定一个匹配的索引，通过一个单独的取索引操作就可以得到要检索的行。在发货事务中也使用了相同的技巧，但此处则没有 DELETE 和 MAXIMUM。

注意，订购项是通过一个单独的游标来检索的。执行两条语句与返回这两个查询的笛卡儿积相比效率要高一些，后者将重复发送每个订购项的客户信息和订单信息。

清单 19 列出的计划展示了使用前面讨论的 ORDER BY 的 (FETCH(8)) 和 FETCH FIRST 1 ROW ONLY 的效率。

清单 19. 订单状态查询计划

Rows
RETURN
(　 1)
CosT
I/O
|
1
NLJOIN
(　 2)
12.928
2.008
/----------+---------
1　　　　　　　　　　　　 1
NLJOIN　　　　　　　　　　TBSCAN
(　 3)　　　　　　　　　　(　10)
12.9279　　　　　　　　4.48727e-005
2.008　　　　　　　　　　　 0
/---------+--------　　　　　　　 |
1　　　　　　　　　　　 1　　　　　　 1
TBSCAN　　　　　　　　　UNION　　TABFNC: SYSIBM
(　 4)　　　　　　　　　(　 5)　　　　GENROW
4.48727e-005　　　　　　　0.108135
0　　　　　　　　　 0.013056
|　　　　　　　　/-------+------
1　　　　　　 1　　　　　　　　　 1
TABFNC: SYSIBM　　 FILTER　　　　　　　FETCH　
GENROW　　　　(　 6)　　　　　　　(　 8)
0.0176324　　　　　0.0905021
0　　　　　　　0.005056
|　　　　　　　 /----+---
0.2　　　 0.005056　　　　 79
IXSCAN　　　 IXSCAN　　TABLE: SRIELAU
(　 7)　　　 (　 9)　　　　ORDERS
0.0158334　　 0.0251716
0　　　　　　0
|　　　　　　|
5　　　　　 79
INDEX: SRIELAU INDEX: SRIELAU
CUST_IDXB　　　ORDR_IDXB