前幾天客戶投訴我們提供的一個訪問Oracle的程序，說運行太慢了，半天都沒有處理完數(shù)據(jù)。
客戶數(shù)據(jù)也就幾十萬條，也不是什么海量數(shù)據(jù)，究竟什么原因呢。而且奇怪的是我們提供的其它類似的程序訪問同一張數(shù)據(jù)表卻沒有任何的問題。
經(jīng)過多次反復寫測試程序，嘗試各種的條件，最后發(fā)現(xiàn)原來是其中一條update語句執(zhí)行很慢，要2秒鐘才更新一條。而這條update語句的where部分有兩個條件，一個是整數(shù)的比較條件，一個是日期的比較條件。當然很容易就可以通過測試排除了整數(shù)條件導致慢的可能性。剩下的原因就是日期比較條件導致慢了。
說得也奇怪，日期條件是通過param的方式傳入?yún)?shù)的，執(zhí)行很慢。但測試的時候如果把日期條件展開，把日期條件變成SQL的一部分，那就執(zhí)行很快了。先不論為什么這么奇怪，要知道Oracle SQL語句的日期條件不是一般的麻煩，都要經(jīng)過TO_DATE/TO_CHAR糊弄來糊弄去，SQL語句跟其他的數(shù)據(jù)庫不一樣，程序就失去通用性了。一定是自己調(diào)用OCI的時候犯了什么糊涂錯誤了。
最后還是發(fā)現(xiàn)有一個不妥當?shù)牡胤剑簲?shù)據(jù)庫字段類型是DATE，而我用OCI綁定param的時候，用的卻是SQLT_TIMESTAMP。原因是我想偷懶，希望用OraDateStruct就解決OCI的日期類型。于是我嘗試用回SQLT_DAT，自己“笨笨的”把時間轉(zhuǎn)換為OCI所能辨認的7個byte的數(shù)組，然后運行程序。速度太快了，一下子就執(zhí)行完了。
其實不明白的是，Oracle發(fā)現(xiàn)類型不匹配，要不就報錯；要不就把條件變?yōu)橄嗳莸臄?shù)據(jù)進行查詢。但是現(xiàn)在從現(xiàn)象看來，Oracle像是把所有保存的數(shù)據(jù)逐個轉(zhuǎn)換成為與條件相容的類型進行判斷，而不是轉(zhuǎn)換條件的類型。所以每次update都變成了遍歷所有的數(shù)據(jù)。難道是存在DBA可以調(diào)整的優(yōu)化策略？？不明白，不明白……