JDBC 的 setTimestamp 性能问题

JDBC日期类型性能问题
本文探讨了通过JDBC进行Java查询时遇到的性能问题,特别是当使用DATE类型的字段进行小范围时间查询时,即使指定了索引也出现了全表扫描的情况。罪魁祸首在于使用setTimestamp()方法绑定值,导致成本模型选择全表扫描而非索引扫描。解决方案是改用setString()方法。

偶然发现三年前的一个技术问题。当时比较匆忙,避免掉即过去了。现在 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 潜在的问题也不少,尽管这个数据类型已经出现多时。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值