本文旨在介紹一種對數據庫中的大數據量表格進行分頁查詢的實現方法，該方法對應用服務器、數據庫服務器、查詢客戶端的cpu和內存占用都較低，查詢速度較快，是一個較為理想的分頁查詢實現方案。

1．問題的提出
在軟件開發中，大數據量的查詢是一個常見的問題，經常會遇到對大量數據進行查詢的場景。

常見的對大數據量查詢的解決方案有以下兩種：

（1）、將全部數據先查詢到內存中，然后在內存中進行分頁，這種方式對內存占用較大，必須限制一次查詢的數據量。

（2）、采用存儲過程在數據庫中進行分頁，這種方式對數據庫的依賴較大，不同的數據庫實現機制不通，并且查詢效率不夠理想。以上兩種方式對用戶來說都不夠友好。

2．解決思路
通過在待查詢的數據庫表上增加一個用于查詢的自增長字段，然后采用該字段進行分頁查詢，可以很好地解決這個問題。下面舉例說明這種分頁查詢方案。

（1）、在待查詢的表格上增加一個long型的自增長列，取名為“queryId”,mssql、sybase直接支持自增長字段，oracle可以用sequence和trigger來實現。然后在該列上加上一個索引。

添加queryId列的語句如下：
Mssql: [QUERYID] [bigint] IDENTITY (1, 1)

Sybase: QUERYID numeric(19) identity

Oracle:
CREATE SEQUENCE queryId_S
INCREMENT BY 1
START WITH 1
MAXVALUE 999999999999999 MINVALUE 1
CYCLE
CACHE 20
ORDER;
CREATE OR REPLACE TRIGGER queryId_T BEFORE INSERT
ON "test_table"
FOR EACH ROW
BEGIN
select queryId_S.nextval into :new.queryId from dual;
END;

（2）、在查詢第一頁時，先按照大小順序的倒序查出所有的queryId，

語句如下：select queryId from test_table where + 查詢條件 +order by queryId desc 。

因為只是查詢queryId字段，即使表格中的數據量很大，該查詢也會很快得到結果。然后將得到的queryId保存在應用服務器的一個數組中。

（3）、用戶在客戶端進行翻頁操作時，客戶端將待查詢的頁號作為參數傳遞給應用服務器，服務器通過頁號和queyId數組算出待查詢的queyId最大和最小值，然后進行查詢。

算出queyId最大和最小值的算法如下,其中page為待查詢的頁號，pageSize為每頁的大小，queryIds為第二步生成的queryId數組：
int startRow = (page - 1) * pageSize
int endRow = page * pageSize - 1;
if (endRow >=queryIds.length)
{
endRow = this.queryIds.length - 1;
}
long startId =queryIds[startRow];
long endId =queryIds[endRow];

查詢語句如下：
String sql = "select * from test_table" + 查詢條件 + "(queryId <= " + startId + " and queryId >= " + endId + ")";

3．效果評價
該分頁查詢方法對所有數據庫都適用，對應用服務器、數據庫服務器、查詢客戶端的cpu和內存占用都較低，查詢速度較快，是一個較為理想的分頁查詢實現方案。經過測試，查詢4百萬條數據，可以在3分鐘內顯示出首頁數據，以后每一次翻頁操作基本在2秒以內。內存和cpu占用無明顯增長。

補充：

不久前我也開發過這樣的一個數據庫，解決的辦法是： 1 硬件方面，提高內存容量（這是最重要的），將更多的內存給予ORACLE固定使用。 2 數據庫方面，拆分大型表單，使用分時間段數據庫，我單位有一個巨型數據也是采用了這種方法?。ㄟ@非常重要，速度可以提高幾十倍左右）。 3 編程方面，盡量不要使用ODBC，采用ORACLE驅動編程，用ODBC太慢。加入每日的統計，加入到你的日報表中去，月底可以加入每月的報表等。 4 看書，查看ORACLE的書籍，對這方面問題應該會有很好的回答（看的書，應該在700頁以上，以清華的書為佳）。

我認為數據分區、分成多個表、增加內存、換更好的機器都是物理上的，當然她帶來的速度的改善是有的。但是性能的改善一般比較少做多10倍到100倍之間。 對Oracle我不熟悉，但在SQL Server中最有效和可行的辦法是優化數據庫結構和索引。 對于優化數據庫有根據事務型和數據倉庫型分為兩個方面。 偏重事務需要插入、更新速度快，所以一般這樣的表索引比較少，字段數目也少 數據倉庫需要查詢速度快，他一般會根據查詢可能出現的條件建立所有的索引，形成所謂的索引覆蓋。在大數據量的數據庫中，一旦某個查詢不能完全利用索引，就會形成表掃描。這是最壞的情況，查詢速度同數據量成正比。而如果能完全利用索引，查詢速度只有在數據量變化幾個等級才會有一些變化。我曾經測試過一個庫存表150條記錄，索引建立不好一個查詢需要4分鐘，對索引優化以后1秒不到。如果數據單純作為查詢可以取消對該表的日志功能。 我一般是分成兩個庫，一個處理事務，一個處理查詢，然后建立一個定期事務把事務數據增加到查詢庫中。 總的來說，只有才所有軟的手段不能解決問題的情況下才采用物理的方法。但是物理的方法也不是單純增加應

總結

以上是生活随笔為你收集整理的大数据量分页查询方法（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。