上文說道了失效效應。只想說明在Performance Tunning方面只能根據情況來尋求原因並解決。這是一 個有意思的過程。大原則是經驗，幫助我們少犯錯誤。因此，糟糕的設計，必然導致性能問題。沒有經驗 的程序員必然會寫出糟糕的代碼。但是良好的設計可以彌補程序員的經驗不足。這個到此打住，這個 topic涉及品質管理，實在太大了。
再看一例，失效效應的體現。
還是上文數說道了2種SQL文 寫法產生的執行計劃。我選用一台雙核的PC，相當於2個單核CPU。
有一個大表TB_CWB。記錄約30 -40萬。（在生產環境下屬於小數據量，在我的測試中可以看成大表）。表上已經對fn_Clt_Datetime 做 了索引。
1.SQL文一
select CWB_No,fn_Clt_Datetime,acctId_guid,fn_OrigZone_Id,DestSZMCode,DestZone_Id,CWBType,fn_Clt_Dat etime,fn_cwbtype,
PayType,Payweight,StdPriceweight,StdFreight,IsCalculated,AFterDsctFreight,
SchgFreight,InvcFreight,Salesamount,SchgDetail,SchgFreight_Remarks
from OCS_TB_CWB
WHERE
fn_Clt_Datetime between '2008-9-1' and '2008 -9-16'
運行結果，發現奇慢無比。需要12秒才能出結果。
檢查執行計劃，發 現用了聚集索引掃描（主鍵），就是相當於選擇了全表掃描的計劃。因為CBO認為這句SQL比動用索引還要 快。見下圖
