From 11 hours to 25 seconds -- is there room for optimization?

2015 year 5 On the day , The customer sent an email asking for help ： One SQL Execution requires 11 Hours , Used in the execution plan nested loops It seems that the efficiency is poor , Can you use hint Let optimizer use hash join, use use_hash Of hint It doesn't seem to work ？

The following is the original text of the customer's email ：

SQL The code is as follows ：

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 Current execution plan ：

Among them the first 7 Step by step nested loops Operation is really the most time-consuming step ：hint It specifies N_SM_PCFC_ORDER_MERGE_02_TMP Watch to do hash join, But it actually uses nested loops Of join Method , And this table is used as the driven table , It is abnormal to use full table scanning .

Carefully analyzed some SQL Code , It is very likely that the business logic in the red part is problematic , So they asked the customer to ask their R & D personnel to confirm , The customer's reply is ：

Tiger Liu thinks that the customer may not really go to R & D for confirmation , So I sent an email to ask for confirmation again , And tell me if this is the right business logic , There is not much room for optimization ：

The customer should really go to R & D for confirmation this time , There is indeed a logic problem . Fixed a SQL Logic and execute , The execution efficiency is still not high ：

Since the customer wants to use the execution plan at the beginning hash join, Then try it first , By the way SQL The actual situation of the execution process , Add two paragraphs first 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) -- Parentheses have been added to correct incorrect logic

) 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;

The result of the first attempt was 687 second , Know that each table passes through predicate conditions and join The approximate number of records returned after , It was also found that , Not all table associations use hash Is the best ：

because NBDL_TCIMS_PCFC_INSURANT Table no INSURANT_CERTIFICATE_NUMBER Index on field , So the second optimization suggestion is ：

Change n Watch making nested loops, Used at the same time leading Adjust the association order of the table ,q Table and n Table interchange position

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;

After the second optimization ,SQL The execution time of is reduced to 25 second （ The degree of parallelism is 4, With primordial SQL The parallelism used is consistent ）

Here we are , Tiger Liu told the customer , If in NBDL_TCIMS_PCFC_INSURANT Tabular INSURANT_CERTIFICATE_NUMBER Create an index on the field , You can do this without using parallelism , The execution time is reduced to 5 About seconds . But the customer thinks the optimization effect is very good , I don't want to build any more indexes .