sql優化 提防錯誤關聯

2021-09-06 10:52:37 字數 2707 閱讀 9982

在寫sql時,在多表關聯時,有時候容易把關聯關係寫錯。一般情況下,該問題比較容易發現,但如果sql較長時,光靠眼力就比較難發現了。今天寫了乙個指令碼,碰到該問題了。

第一版本的指令碼如下:

select detail.commityear,

detail.commitmonth,

to_char((sysdate - 1), 'yyyymm') statmonthid,

policy.corppkno,

product.prdtsubcatpkno,

product.pkno,

sum(loss_d.losssum) losssum_fash,

sum(claim_d.claimsum) claimsum_fash,

sum(indemnity_d.indemnityrptdetail) indemnityrpt_fash,

sum(recovery_d.recoverysumdetail) recoveryrpt_fash

from f_t_declaredetail detail

join stdw.d_t_policy policy

on detail.policypkno = policy.pkno

join stdw.d_t_producttype product

on policy.policytypepkno = product.pkno

left join (select t.declaredetailpkno,

sum(nvl(t.losssumdetail, 0)) losssum

from stdw.f_t_lossdetail t

group by t.declaredetailpkno) loss_d

on detail.pkno = loss_d.declaredetailpkno

and loss_d.losssum > 0

left join (select claim.declaredetailpkno,

sum(nvl(claim.claimsumdetail, 0)) claimsum

from stdw.f_t_claimdetail claim

group by claim.declaredetailpkno) claim_d

on detail.pkno = claim_d.declaredetailpkno

and claim_d.claimsum > 0

left join (select declaredetailpkno,

sum(nvl(indemnityrptdetail, 0)) indemnityrptdetail

from stdw.f_t_indemnitydetail

group by declaredetailpkno) indemnity_d

on detail.pkno = indemnity_d.declaredetailpkno

and indemnity_d.indemnityrptdetail > 0

left join (select declaredetailpkno,

sum(nvl(recoverysumdetail, 0)) recoverysumdetail

from stdw.f_t_recoverydetail

group by declaredetailpkno) recovery_d

on detail.pkno = indemnity_d.declaredetailpkno

and recovery_d.recoverysumdetail > 0

where product.pkno not in (7, 8, 12, 14, 38) /*有出運*/

and (loss_d.losssum is not null or claim_d.claimsum is not null or

indemnity_d.indemnityrptdetail is not null or

recovery_d.recoverysumdetail is not null) /*剔除沒有報損等資訊的資料*/

group by detail.commityear,

detail.commitmonth,

policy.corppkno,

product.prdtsubcatpkno,

product.pkno

執行後,發現半天沒出來數。而且這些表中,資料量最大的表f_t_declaredetail也就幾百萬條,在極致情況下,最多返回幾百萬行資料。檢視了下執行計畫,發現執行計畫和預計的不一樣,而且預估的結果集相當大。執行計畫如下:

根據圖示,可以比較清楚的看到,表f_t_recoverydetail居然與其他的表做了內嵌迴圈關聯,不可思議啊,而且返回的結果集,遠超百萬數量級,比f_t_declaredetail的數量級還大。起初以為是統計資訊出了問題,檢視了各表的統計資訊,發現沒有什麼異常。

後來靜下來想了想,返回的結果集肯定不會超過f_t_declaredetail的資料量,正好與f_t_recoverydetail關聯時,資料量嗖地上去了,初步懷疑是關聯的問題。可以回頭看下sql**,粗字型表明的地方就是問題所在:確實是表之間關聯出了問題。

總結:有時候肉眼看不出來,就用執行計畫看吧,還是有很大幫助的。呵呵

sql優化 提防錯誤關聯

sql優化 提防錯誤關聯 在寫sql時,在多表關聯時,有時候容易把關聯關係寫錯。一般情況下,該問題比較容易發現,但如果sql較長時,光靠眼力就比較難發現了。今天寫了乙個指令碼,碰到該問題了。第一版本的指令碼如下 sql select detail.commityear,detail.commitmo...

sql優化 提防錯誤關聯

在寫sql時,在多表關聯時,有時候容易把關聯關係寫錯。一般情況下,該問題比較容易發現,但如果sql較長時,光靠眼力就比較難發現了。今天寫了乙個指令碼,碰到該問題了。第一版本的指令碼如下 select detail.commityear,detail.commitmonth,to char sysda...

時刻提防 一些關於搜尋引擎優化方面錯誤

好久沒有寫seo方面的東西了,今天寫了一些關於搜尋引擎優化方面的錯誤,這些錯誤會導致搜尋引擎忽略你 訪客忽視你,還有可能使得訪問者從你的 流失掉。用過多的flash 要知道,由於搜尋引擎技術原因,無法檢索到flash中的內容,因此,在 中使用過多的flash會適得其反。而且 使用過多的flash,會...