sql優化-提防錯誤關聯
在寫sql時，在多表關聯時，有時候容易把關聯關係寫錯。一般情況下，該問題比較容易發現，但如果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較長時，光靠眼力就比較難發現了。今天寫了乙個指令碼，碰到該問題了。第一版本的指令碼如下 select detail.commityear,detail.commitmonth,to char sysda...
sql優化 提防錯誤關聯
在寫sql時，在多表關聯時，有時候容易把關聯關係寫錯。一般情況下，該問題比較容易發現，但如果sql較長時，光靠眼力就比較難發現了。今天寫了乙個指令碼，碰到該問題了。第一版本的指令碼如下 select detail.commityear,detail.commitmonth,to char sysda...
時刻提防 一些關於搜尋引擎優化方面錯誤
好久沒有寫seo方面的東西了，今天寫了一些關於搜尋引擎優化方面的錯誤，這些錯誤會導致搜尋引擎忽略你 訪客忽視你，還有可能使得訪問者從你的 流失掉。用過多的flash 要知道，由於搜尋引擎技術原因，無法檢索到flash中的內容，因此，在 中使用過多的flash會適得其反。而且 使用過多的flash，會...