从11小时到25秒--还有优化空间吗？

2015年5月的一天，客户发来邮件请求帮助：一个SQL执行需要11个小时，执行计划中使用nested loops好像效率差了些，能不能用hint让优化器使用hash join，用use_hash 的 hint好像没生效？

下面是客户邮件原文截取：

SQL代码如下：

SELECT DISTINCT N.ID_NBDL_TCIMS_PCFC_ORDER, M.POLICY_NO, N.POLICY_NO

FROM (SELECT /*+ USE_HASH(R,C) */

C.ID_BSE_TCIMS_PCFC_ORDER,

C.PRODUCT_CODE,

D.INSURANT_CERTIFICATE_NUMBER,

C.DATE_BEGIN,

C.POLICY_NO

FROM N_SM_PCFC_ORDER_MERGE_02_TMP R,

BSE_TCIMS_PCFC_ORDER_BM_TMP C,

BSE_TCIMS_PCFC_INS_BM_TMP D

WHERE R.TCIMS_LIST_ID IS NULL

AND R.RN = 1

AND R.ID_NBDL_TCIMS_PCFC_ORDER = C.ID_BSE_TCIMS_PCFC_ORDER

AND C.ID_BSE_TCIMS_PCFC_ORDER = D.ID_BSE_TCIMS_PCFC_ORDER

AND C.PARENT_POLICY_NO IS NULL OR INSTR(C.PARENT_POLICY_NO, 'tmp') > 0

) M,

NBDL_TCIMS_PCFC_ORDER N,

NBDL_TCIMS_PCFC_INSURANT Q,

BDL_TCIMS_PCFC_TB_PRODUCT K

WHERE M.INSURANT_CERTIFICATE_NUMBER = Q.INSURANT_CERTIFICATE_NUMBER

AND M.PRODUCT_CODE = K.NEW_PRODUCT_CODE

AND N.PRODUCT_CODE = K.LAST_PRODUCT_CODE

AND (M.DATE_BEGIN + 98) >= N.DATE_END

AND N.DATE_END + 30 >= M.DATE_BEGIN

AND N.POLICY_TYPE = 'NB'

AND N.ID_NBDL_TCIMS_PCFC_ORDER = Q.ID_NBDL_TCIMS_PCFC_ORDER;

SQL当前执行计划：

其中第7步的nested loops操作确实是最消耗时间的一步：hint指定了N_SM_PCFC_ORDER_MERGE_02_TMP表要做hash join，但实际上还是使用了nested loops 的join 方法，而且该表做为被驱动表，使用全表扫描不正常。

仔细分析了一些SQL代码，发现红色部分的业务逻辑极有可能是有问题的，于是请求客户找他们的研发人员确认，客户答复是这样的：

老虎刘觉得客户可能没有真正去找研发去确认，于是发邮件再次请求确认，并告知如果这就是正确的业务逻辑，可优化的空间也不大：

客户这次应该真的找研发确认了，确实是逻辑有问题。修正了SQL逻辑并执行，执行效率还是不高：

既然客户一开始想让执行计划都使用hash join，那么先尝试一下，顺便收集一下SQL执行过程的实际情况，先加两段hint：

SELECT /*+ leading(k m n q) use_hash(m) use_hash(n) use_hash(q) */

DISTINCT N.ID_NBDL_TCIMS_PCFC_ORDER, M.POLICY_NO, N.POLICY_NO

FROM (SELECT /*+ no_merge leading(r c d) use_hash(c) use_hash(d)*/

C.ID_BSE_TCIMS_PCFC_ORDER,

C.PRODUCT_CODE,

D.INSURANT_CERTIFICATE_NUMBER,

C.DATE_BEGIN,

C.POLICY_NO

FROM N_SM_PCFC_ORDER_MERGE_02_TMP R,

BSE_TCIMS_PCFC_ORDER_BM_TMP C,

BSE_TCIMS_PCFC_INS_BM_TMP D

WHERE R.TCIMS_LIST_ID IS NULL

AND R.RN = 1

AND R.ID_NBDL_TCIMS_PCFC_ORDER = C.ID_BSE_TCIMS_PCFC_ORDER

AND C.ID_BSE_TCIMS_PCFC_ORDER = D.ID_BSE_TCIMS_PCFC_ORDER

AND (C.PARENT_POLICY_NO IS NULL OR INSTR(C.PARENT_POLICY_NO, 'tmp') > 0) --已增加括号修正错误逻辑

) M, --14k

NBDL_TCIMS_PCFC_ORDER N, --165w

NBDL_TCIMS_PCFC_INSURANT Q,--1700w

BDL_TCIMS_PCFC_TB_PRODUCT K--75

WHERE M.INSURANT_CERTIFICATE_NUMBER = Q.INSURANT_CERTIFICATE_NUMBER

AND M.PRODUCT_CODE = K.NEW_PRODUCT_CODE

AND N.PRODUCT_CODE = K.LAST_PRODUCT_CODE

AND (M.DATE_BEGIN + 98) >= N.DATE_END AND N.DATE_END + 30 >= M.DATE_BEGIN

AND N.POLICY_TYPE = 'NB' --165w

AND N.ID_NBDL_TCIMS_PCFC_ORDER = Q.ID_NBDL_TCIMS_PCFC_ORDER;

第一次尝试的结果是687秒，知道了各表经过谓词条件和join 后返回的大致记录数，同时也发现，并不是全部的表关联都使用hash才是最优的：

因为NBDL_TCIMS_PCFC_INSURANT表没有INSURANT_CERTIFICATE_NUMBER字段上的索引，所以第二次给出的优化建议是：

改n表做nested loops，同时用过leading调整表的关联顺序，q表与n表互换位置

SELECT /*+ leading(k m q n) use_hash(m) use_hash(q) use_nl(n) */

DISTINCT N.ID_NBDL_TCIMS_PCFC_ORDER, M.POLICY_NO, N.POLICY_NO

FROM (SELECT /*+ no_merge leading(r c d) use_hash(c) use_hash(d)*/

C.ID_BSE_TCIMS_PCFC_ORDER,

C.PRODUCT_CODE,

D.INSURANT_CERTIFICATE_NUMBER,

C.DATE_BEGIN,

C.POLICY_NO

FROM N_SM_PCFC_ORDER_MERGE_02_TMP R,

BSE_TCIMS_PCFC_ORDER_BM_TMP C,

BSE_TCIMS_PCFC_INS_BM_TMP D

WHERE R.TCIMS_LIST_ID IS NULL

AND R.RN = 1

AND R.ID_NBDL_TCIMS_PCFC_ORDER = C.ID_BSE_TCIMS_PCFC_ORDER

AND C.ID_BSE_TCIMS_PCFC_ORDER = D.ID_BSE_TCIMS_PCFC_ORDER

AND (C.PARENT_POLICY_NO IS NULL OR INSTR(C.PARENT_POLICY_NO, 'tmp') > 0)

) M, --14k

NBDL_TCIMS_PCFC_ORDER N, --165w

NBDL_TCIMS_PCFC_INSURANT Q,--1700w

BDL_TCIMS_PCFC_TB_PRODUCT K--75

WHERE M.INSURANT_CERTIFICATE_NUMBER = Q.INSURANT_CERTIFICATE_NUMBER

AND M.PRODUCT_CODE = K.NEW_PRODUCT_CODE

AND N.PRODUCT_CODE = K.LAST_PRODUCT_CODE

AND (M.DATE_BEGIN + 98) >= N.DATE_END AND N.DATE_END + 30 >= M.DATE_BEGIN

AND N.POLICY_TYPE = 'NB' --165w

AND N.ID_NBDL_TCIMS_PCFC_ORDER = Q.ID_NBDL_TCIMS_PCFC_ORDER;

第二次优化后，SQL的执行时间减少到25秒（并行度为4，与原始SQL使用的并行度一致）

到了这一步，老虎刘告诉客户，如果在NBDL_TCIMS_PCFC_INSURANT表的INSURANT_CERTIFICATE_NUMBER字段上创建一个索引，可以在不使用并行的情况下，执行时间减少到5秒左右。但是客户已经觉得优化效果非常好了，不想再去建什么索引了。