通过 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_firs

清单 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。

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