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