如果你在Oracle版本驅動中使用Java Date時產生一些問題的時候，你是否想了解不解之處，以下的文章主要是通過對Oracle版本驅動中使用Java Date的問題的實際應用的方案的介紹，來解答你在Oracle版本驅動中使用Java Date的問題在實際操作方面的問題。

這里兩天都在對一條sql進行調優。該sql并不復雜,類似于

select ... from some_view union all select ... 
from some_table where datetime >= d1 and datetime< d2 and ....  

底層使用

ibatis2.1.6 + oracle 10g 

今天花了些時間繼續研究這個問題，導致該問題的原因的確是“導致oracle對datetime字段進行了隱式類型轉換，最終CBO未能使用該列的全局索 引”，不過問題不是出在ibatis上而是Oracle driver。設我們使用這樣的sql通過綁定變量(類型為java.util.date)查詢數據庫，其中end_date是date類型且建立了索引。

“select count(*) from table1 where end_date >=
 :1 and end_date <= :2” 

通常，面對這樣的sql，我們希望它的執行計劃走index range scan。然而在默認情況下oracle CBO是不會選擇走索引地，以上面這語句為例，oracle實際走的是table full scan。為什么會這樣 呢？這類問題是oracle版本在9.2以后引入了TIMESTAMP才開始出現的。

在 9.2之前，Oracle只有DATE，而沒有TIMESTAMP。在jdbc preparedStatement.setTimestamp時，綁定變量的類型會被正確的設置為DATE。而在9.2之后，oracle開始支持 TIMESTAMP了，這兩者都能支持精度為yyyy-MM-dd hh24:mi:ss的時間（當然TIMESTAMP能支持到納秒級別）。

但jdbc driver的api未變同樣在preparedStatement.setTimestamp時，oracle driver就得選擇到底該把綁定變量的類型設置為DATE還是TIMESTAMP呢？估計是由于TIMESTAMP的精度更高，Oracle 最終默認選擇了將綁定變量的類型設置為了TIMESTAMP。那么這個時候，如果面對實際屬性為DATE的列，那么就會導致 oracle隱式地進行形如

“TO_TIMESTAMP(date_column) = parameter_timestamp” 

轉換，要 知道oracle CBO不會選擇被某函數作用的列上的索引，除非是函數索引。因此，最終也會導致最上面的情況使用table full scan而不是index range scan。

Oracle版本就沒有提供別的方法來正確地提供綁定變量嗎？oracle提供 了幾個方法來解決這個問題

1.升級到11g并使用新的正確的driver api。

2.將DATE列全都改成 TIMESTAMP列。

3.使用V8Compatible flag。

以上就是對Oracle版本驅動中如何使用Java Date的相關的內容的介紹，望你會有所收獲。

【編輯推薦】

1. 檢查Oracle DICOM 對象的典型示例
2. Oracle ID 自增代碼的詳細介紹
3. 對Oracle Multimedia導出圖像的操作步驟的描述
4. 在Oracle模式中定義媒體對象有哪些
5. Oracle Multimedia在ORDDicom中列中存儲DICOM詳解