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