以下的文章我們主要介紹的是Oracle JDBC 的 setTimestamp 的相關(guān)的性能問題，我前兩天在相關(guān)網(wǎng)站看見Oracle JDBC 的 setTimestamp 的相關(guān)的性能問題的資料，覺得挺好，就拿出來供大家分享。

偶然發(fā)現(xiàn)三年前的一個(gè)技術(shù)問題。當(dāng)時(shí)比較匆忙，避免掉即過去了。現(xiàn)在 Metalink 上其實(shí)已經(jīng)把這個(gè)問題作為一個(gè) Bug 處理了。

問題描述：通過 JDBC 上來的 Java 查詢應(yīng)用，SQL 表現(xiàn)異常。表字段使用了 DATE 類型，針對該字段時(shí)間區(qū)域很小的范圍查詢(預(yù)期應(yīng)該是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，發(fā)現(xiàn)無效。仍然是 FULL TABLE SCAN 。

罪魁禍?zhǔn)祝簊etTimestamp() 把值綁定為 TIMESTAMP 類型，這樣和 DATA 類型比較的時(shí)候，CBO 就會選擇全表掃描。

通過 Trace 能觀察到該異常行為。TIMESTAMP 在 Oracle JDBC 9.2.0.1 上就有了，連續(xù)幾個(gè)版本其實(shí)都有類似的問題。

解決辦法：使用 setString() 而不是 setTimestamp() 方法。

這個(gè)故事告訴我們，Oracle JDBC 其實(shí)問題挺多的。同樣，TIMESTAMP 潛在的問題也不少。

以上的相關(guān)內(nèi)容就是對Oracle JDBC 的 setTimestamp 性能問題的介紹，望你能有所收獲。

文章出自: http://www.programbbs.com/doc/3296.htm

【編輯推薦】

1. Oracle EM管理 MySQL的實(shí)操方案
2. Oracle In-Memory Undo特性淺談
3. Oracle DRCP與PHP的不同之處
4. Oracle 語句的優(yōu)化規(guī)則中的相關(guān)項(xiàng)目
5. Oracle sql 性能如何進(jìn)行調(diào)整