oracle时间范围查询优化_从 TPCH 测试学习性能优化技巧之 Q13

一、 查询要求

Q13语句查询获得消费者的订单数量，包括过去和现在都没有订单记录的消费者。

Q13语句的特点是：带有分组、排序、聚集、子查询、左外连接操作并存的查询操作。

二、 Oracle执行

Oracle编写的查询SQL语句如下：

select /*+ parallel(n) */

c_count,

count(*) as custdist

from (

select

c_custkey,

count(o_orderkey) c_count

from

customer left outer join orders on

c_custkey = o_custkey

and o_comment not like '%special%accounts%'

group by

c_custkey

) c_orders

group by

c_count

order by

custdist desc,

c_count desc;

其中/*+ parallel(n) */ 是Oracle的并行查询语法，n是并行数。

脚本执行时间，单位：秒

三、 SPL优化

这个查询简单看是对orders做两轮常规分组，第一轮按custkey分组计算出每个顾客的下单数，第二轮再按下单数分组计算出每种下单数各有多少顾客。

注意到原SQL中有个左连接，会将没有下单过的顾客(下单数为0)也统计在内，而上述二轮分组过程则会遗漏掉这些数据，需要事后再补充一下。

SPL脚本如下：

A5做第一轮分组，A7做第二轮；A8计算所有客户数，减去已下单的就是没下单的客户数，补充到A7上再一起排序。

脚本执行时间，单位：秒

这个查询SPL没有跑过Oracle，绝大部分时间消耗在第一轮分组(A5)。主要原因在于这里的分组结果集较大，会占用很多内存，而SPL目前还是Java开发，JVM对内存的管理较差，占用内存较多时就会频繁发起垃圾收集动作，消耗很多时间。而C++开发的数据库则没有这个问题。

四、 进一步优化

SPL中groups函数在分组时，如果分组字段是序号，那么可以用@n选项直接定位，避免hash计算。本例中第一轮按O_CUSTKEY分组的，而在数据表中O_CUSTKEY都是整数，可以尝试@n选项。但本例中O_CUSTKEY的值较大，也就是分组数多，占用内存大，并行线程多时如果每个线程中都分一个大组，内存将不够用，所以并行数多时，要减少groups@n的并行数。本例中使用的方法是并行数小于3时就用原并行数，大于3时就用它整除4所得的商。

SPL脚本如下：

脚本执行时间，单位：秒

测试结果可见，效率确实有所提高，在低并行时性能超过了Oracle，高并行时因为内存占用过大导致垃圾收集时间消耗过多而又被Oracle反超。