2015年5月的一天，客户发来邮件请求帮助：一个SQL执行须要11个小时，执行计划中使用nested loops好像效率差了些，能不能用hint让优化器使用hash join，用use_hash 的 hint好像没生效？sql
下面是客户邮件原文截取：性能优化
SQL代码以下：微信
SELECT DISTINCT N.ID_NBDL_TCIMS_PCFC_ORDER, M.POLICY_NO, N.POLICY_NOoracle
FROM (SELECT /*+ USE_HASH(R,C) */oop
C.ID_BSE_TCIMS_PCFC_ORDER,性能
C.PRODUCT_CODE,优化
D.INSURANT_CERTIFICATE_NUMBER,ui
C.DATE_BEGIN,spa
C.POLICY_NO.net
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秒左右。可是客户已经以为优化效果很是好了，不想再去建什么索引了。
关注“老虎刘谈SQL优化”，分享老虎刘那些年的SQL优化案例！
脚本分享在QQ群：16778072
为了方便你们与老虎刘交流，新建了一个微信群：名字也是老虎刘谈SQL优化
本文分享自微信公众号 - 老虎刘谈oracle性能优化（sql_tigerliu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。