因 Oracle 8.0.5 不支持子查询排序,为改善原来那种每次翻页时都捋出所有数据成对象到 List 中,然后从中拣取页面实际要显示的记录的性能问题时,采用了 rs.absolute() 直接跳到起始记录游标的方法,但又引入了乱码问题,例如:"无效",变成了 "0xE697A0E69588"。
虽说,换个驱动,如 8.1.7.0.0 以上版本的驱动就能解决乱码的问题,但这一换又怕会影响到其他的应用。有朋友评论说,其实循环 next() 到某处比 absolute() 定位要好,乍一看,有些牵强,不过试试就知道了。下面就来做样一个测试,测试代码如下:
测试环境:
Oracle 数据库 8.0.5.1.0
驱动文件:classes12.zip
驱动版本:8.1.6.0.0
驱动类:oracle.jdbc.driver.OracleDriver
测试数据(未列出每一次的测试数据,只求了不同条件下的平均值,startCuror 为定位的游标位置,stepByStep 表示是用 n 次 next() 移动游标,还是用 absolute(n) 直接定位,true 为前者):
换着用 8.1.7.0.0, 9.0.1.1.0 这两个版本的驱动,和连接到 9.2.0.1.0 版本的数据库测试得出来的数据都相仿。由测试数据大致可以得出如下结论:
1. 用 absolute(n) 比循环 n 次 next() 定位游标的时间要稍长,但不是很明显。也许这只是跟 ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY 类型的 Statement 有关。
2. 创建了 ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY 类型的 Statement 时,取数据记录的时候也会慢一些,也不是很明显。
3. 但最后一点是始料未及的--居然产生了内存溢出。移动游标到 500000 的位置时,用 next() 循环没问题,用 absolute 无论是连接 Oracle 8.0.5.1.0 还是 Oracle 9.2.0.1.0 时均告 OutOfMemoryError。可见 absolute,或者是 ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY 类型的 Statement 占用内存会比较大。看起来似乎真的在执行 absolute(n) 方法的时候预读了数据到内存中。
前面一直是关注 absolute(n) 和 n 次 next() 的速度问题,未考虑到 Statement 本身类型的问题,所以还需看看对 ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY 类型的 Statement 进行 n 次 next() 效果,会如何,是否在 500000 次 next() 也会像 absolute(500000) 那样产生 OutOfMemoryError 堆内存溢出异常,这还有待于求证。
- 大小: 85.8 KB
- 大小: 10 KB
分享到:
相关推荐
通过以上几个方面的详细探讨,我们不仅可以更好地理解JDBC中`ResultSet`的使用方法,还可以掌握如何正确配置数据库连接以及了解数据库管理系统的特有功能。这对于实际开发工作中处理数据库操作具有重要的指导意义。
rs.absolute(9000); // 移动到第9000行 ``` ##### 批量更新 1. **使用`Statement`进行批量更新**: ```java Statement sm = cn.createStatement(); sm.addBatch(sql1); sm.addBatch(sql2); // ... int[] ...
早期版本的JDBC(Java Database Connectivity)并未提供很好的支持,如JDBC 1.0版本仅能使用`next()`方法遍历结果集,无法直接获取结果集的大小,这使得分页功能难以实现。随着JDBC 2.0的发布,虽然提供了更好的支持...
rs.absolute((currentPage - 1) * pageSize + 1); // 显示数据 while (rs.isBeforeLast() && !rs.isAfterLast()) { // 处理数据... rs.next(); } ``` 这种方法虽然简单,但当数据量较大时,一次性加载所有数据...
然而,JSP与后端数据库交互时,尤其是在使用JDBC(Java Database Connectivity)进行数据检索的过程中,分页并非易事。JDBC早期版本在设计时并未充分考虑分页需求,直到JDBC 2.0引入了向前及向后滚动的ResultSet特性...
- 在数据量较大时,一次性加载所有数据可能会消耗大量内存资源。 - 查询性能受限于网络传输速度和数据库响应时间,尤其是在数据量较大时。 #### 总结 综合来看,每种分页技术都有其适用场景和局限性。选择合适的...
在实际项目中,通常不推荐使用`Vector`来实现分页功能,而更倾向于直接使用JDBC提供的功能。这是因为`Vector`存在以下问题: - 性能问题:随着数据量的增长,`Vector`的操作性能会逐渐下降。 - 内存消耗:存储大量...
如果`hibernate.jdbc.use_scrollable_resultset`配置为`true`,则Hibernate会尝试使用JDBC的`ResultSet`接口提供的`absolute`方法直接跳转到指定的位置,从而实现快速定位和分页。 ```java if (session.getFactory...