JDBC 的 setTimestamp 性能问题

偶然发现三年前的一个技术问题。当时比较匆忙,避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。

问题描述:通过 JDBC 上来的 Java 查询应用,SQL 表现异常。表字段使用了 DATE 类型,针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN),在 SQL Map 上指定索引,发现无效。仍然是 FULL TABLE SCAN (FTS)。

罪魁祸首:setTimestamp() 把值绑定为 TIMESTAMP 类型,这样和 DATE 类型比较的时候,CBO 就会选择全表扫描。

通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了,连续几个版本其实都有类似的问题。

解决办法:使用 setString() 而不是 setTimestamp() 方法。

这个故事告诉我们,Oracle 的 JDBC 驱动程序其实问题挺多的。同样,TIMESTAMP 潜在的问题也不少,尽管这个数据类型已经出现多时。

--EOF--

| | TrackBacks (0) | | Edit

Generator | Trampoline | 外贸英才网 | Vinyl fence
Vertical Packaging Machine | Digital Blood Pressure Monitor

自定义搜索

本文相关评论|Comments(4)

flycondor 的评论:

DATA?
是DATE吧?

chenzugang 的评论:

烦请您说的详细一些,如果使用 setString() 而不是 setTimestamp() 方法,sql语句岂不是要改变?

Fenng 的评论:

@chenzugang

你不是 Java 开发人员吧? 这个和 SQL 改动有什么关系?

Fenng Author Profile Page 的评论:

@flycondor

更正了

添加评论

关于这篇文章

这篇文章由 Fenng 于 June 20, 2008 4:44 PM 发布

上一篇:InfoQ 数据库架构采访文字修正稿(2)

下一篇:看 Twitter 人谈架构扩展问题

回到首页查看最近的文章或者是查看所有归档文章

DBA notes 的订阅数量,点击则可进行订阅
Feed 订阅数量,点击即可订阅最新内容