由DB2分页想到的,关于JDBC ResultSet 处理大数据量

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

最近在处理DB2 ,查询中，发现如下问题。如果一个查询 count(*),有几十万行，分页如何实现

select row_number() over (order by fid desc ) as row_number, other_field

from loaddata

如果这个查询的结果会返回几十万行，如何分页：

1 order by fid desc 中 fid 这个字段一定要建立索引，且建立索引时，要根据sql中的排序方式保持一致

2 如何分页

方法1 select * from (

select row_number() over (order by fid desc ) as row_number, other_field

from loaddata

) a

where a. row_number > 500

fetch first 100 rows only

解释：

500 :这个值，根据当前页数及每页的数量进行计算得到

关键在于，定位到起始行

而 fetch first 100 rows only ,假设每页显赫 10数据，那么，用fetch ，是非常有重要的性能提升方法

方法2 如果用如下的 sql

select * from (

select row_number() over (order by fid desc ) as row_number, other_field

from loaddata

) a

where a. row_number > 500 and row_number <510

--- fetch first 100 rows only

随着表中数量增大，和翻页数量的增加，这个查询的速度是会显著的下降。

方法1 在分页上百万的数据，只需花费 100多毫秒。

而方法2 当分页总数在 20多万行，查询row_number在 5000到 5010之间的记录时时会达到 1分钟以上下

--------------------------------------------------------------------------------------------------------------------------------------------------

如果用JDBC查询这上百万条数据，速度如何。分批查询。这合我想到了ResultSet的原理。各个驱动不尽相同。

客户端内存是否会想当然的溢出？

于是用JDBC实验了一下。发现客户端内存并的消耗并没有显著提升。

事实上用JDBC ResultSet查询如此多的数据,会存在连接超时的问题

------------------------------------------------------------------找到如下资料说明 --------------------------------------------------------------------------

问题描述：在通常的三层构架下，客户通过Browser请求Web服务器查询数据库，而查询结果是上千条甚至是上百万条记录，要求查询结果传送到客户端浏览器并分页显示。

考虑因素：

1. Web服务器的资源消耗，包括：内存（用来存储查询结果），数据库相关资源（数据库连接对象，ResultSet对象等等）；

2. DB服务器资源的消耗，包括游标，会话等等。

3. 网络开销，包括与数据库建立会话，传输查询结果等等。

JDBC中的几个重要Class:

A ResultSet object maintains a cursor pointing to its current row of data. Initially the cursor is positioned before the first row. The next method moves the cursor to the next row, and because it returns false when there are no more rows in the ResultSet object, it can be used in a while loop to iterate through the result set.

ResultSet是直接在数据库上建立游标，然后通过ResultSet的行位置定位接口来获得指定行位置的记录。当用户通过get方法获取具体纪录的内容时，ResultSet才从数据库把所需数据读到客户端。

Oracle的ResultSet实现似乎会在本地缓存用户读取过的数据，导致内存消耗会随读取数据的增加而增加，这样，如果一次查询并读取海量数据，即使读出数据后马上丢弃（比如直接写入文件），内存消耗也会随查询结果的增加而递增。

The RowSet interface extends the standard java.sql.ResultSet interface. A RowSet object may make a connection with a data source and maintain that connection throughout its life cycle, in which case it is called a connected rowset. A rowset may also make a connection with a data source, get data from it, and then close the connection. Such a rowset is called a disconnected rowset. A disconnected rowset may make changes to its data while it is disconnected and then send the changes back to the original source of the data, but it must reestablish a connection to do so.

RowSet是JDBC2.0中提供的接口,Oracle对该接口有相应实现，其中很有用的是 oracle.jdbc.rowset.OracleCachedRowSet。 OracleCachedRowSet实现了ResultSet中的所有方法，但与ResultSet不同的是，OracleCachedRowSet中的数据在Connection关闭后仍然有效。

解决方案一：直接使用ResultSet来处理

从ResultSet中将查询结果读入collection,缓存在HttpSession或有状态bean中，翻页的时候从缓存中取出一页数据显示。这种方法有两个主要的缺点：一是用户可能看到的是过期数据；二是如果数据量非常大时第一次查询遍历结果集会耗费很长时间，并且缓存的数据也会占用大量内存，效率明显下降。

对上述方法的一种改进是当用户第一请求数据查询时，就执行SQL语句查询，获得的ResultSet对象及其要使用的连接对象都保存到其对应的会话对象中。以后的分页查询都通过第一次执行SQL获得的ResultSet对象定位取得指定页的记录（使用rs.last();rs.getRow()获得总计录条数，使用rs.absolute()定位到本页起始记录）。最后在用户不再进行分页查询时或会话关闭时，释放数据库连接和ResultSet对象等数据库访问资源。每次翻页都只从ResultSet中取出一页数据。这种方式在某些数据库(如oracle)的JDBC实现中差不多也是回缓存所有记录而占用大量内存，同时速度也非常慢。

在用例分页查询的整个会话期间，一个用户的分页查询就要占用一个数据库连接对象和结果集的游标，这种方式对数据库的访问资源占用比较大，并且其利用率不是很高。

优点：减少了数据库连接对象的多次分配获取，减少了对数据库的SQL查询执行。

缺点：占用数据库访问资源－数据库连接对象，并占用了数据库上的资源－游标；会消耗大量内存；

解决方案二：定位行集SQL查询

使用数据库产品提供的对查询的结果集可定位行范围的SQL接口技术。在用户的分页面查询请求中，每次可取得查询请求的行范围的参数，然后使用这些参数生产取得指定行范围的的SQL查询语句，然后每次请求获得一个数据库连接对象并执行SQL查询，把查询的结果返回给用户，最后释放说有的数据库访问资源。

这种方式需要每次请求时都要执行数据库的SQL查询语句；对数据库的访问资源是使用完就立即释放，不白白占用数据库访问资源。对特定（提供了对查询结果集可定位功能的）的数据库产品，如：Oracle（rowid或rownum ）,DB2（rowid或rownum ()）, PostgreSQL（LIMIT 和 OFFSET）,mySQL（Limit）等。(MS SQL Server 没有提供此技术。)

下面是在oracle下的查询语句示例：

SELECT * FROM ( SELECT row_.*, rownum rownum_ FROM (...... ) row_ WHERE rownum <= {pageNumber*rowsPerPage}) WHERE rownum_ > {(pageNumber-1)*rowsPerPage}

优点：对数据库的访问资源（数据库连接对象，数据库游标等）没有浪费，这些资源的充分重复的利用。

缺点：对每次分页面查询请求要频繁的从Web容器中获得数据库访问资源（数据库连接对象和数据库游标）并建立连接；要依赖于具体的数据库产品的支持。