Oracle JDBC 驅動隱式類型轉換導致索引失效：Date/Timestamp 綁定陷阱

一條簡單的日期範圍查詢，明明有索引卻走全表掃描？罪魁禍首是 Oracle 9.2+ 引入 TIMESTAMP 類型後，JDBC 驅動默認將 java.util.Date 綁定為 TIMESTAMP，觸發隱式轉換 TO_TIMESTAMP(date_col) = :bind，導致 CBO 放棄索引。本文深度解析機制並給出三大解決方案。

一、問題復現

-- 表結構
CREATE TABLE t1 (end_date DATE);
CREATE INDEX idx_t1_end_date ON t1(end_date);

-- Java 代碼
PreparedStatement ps = conn.prepareStatement(
  "SELECT COUNT(*) FROM t1 WHERE end_date >= ? AND end_date <= ?");
ps.setTimestamp(1, startDate);  // java.util.Date
ps.setTimestamp(2, endDate);

執行計劃：TABLE ACCESS FULL（預期 INDEX RANGE SCAN）

二、根因深度剖析

1. Oracle 9.2 前僅有 DATE，setTimestamp 綁定類型為 DATE。
2. 9.2+ 引入 TIMESTAMP（納秒精度），驅動為「精度更高」默認綁定為 TIMESTAMP。
3. 列類型為 DATE，Oracle 隱式轉換：TO_TIMESTAMP(end_date) = :bind_ts。
4. CBO 規則：**函數作用列上的索引不可用**（除非建函數索引）。
5. 結果：全表掃描，性能災難。

三、三大解決方案

四、驗證方法

-- 開啟 10046 追蹤或查看 V$SQL_BIND_DATA
SELECT sql_text, bind_type, datatype
FROM v$sql_bind_capture
WHERE sql_id = '...';

確認 DATATYPE = 12 (DATE) 而非 180 (TIMESTAMP)。

五、最佳實踐建議

• 新系統：統一使用 TIMESTAMP WITH TIME ZONE + 驅動新 API。
• 舊系統：連接池層面統一添加 V8Compatible=true，最低改動成本。
• 代碼規範：DAO 層日期參數統一用 java.sql.Date（純日期）或 java.sql.Timestamp，避免 java.util.Date 歧義。
• 索引審計：定期掃描執行計劃中 TO_TIMESTAMP/TO_DATE 隱式轉換模式。