虽然 DataGrid 控件自己带了一个分页处理机制，但它是将符合查询条件的所有记录读入内存，然后进行分页显示的。随着符合条件的记录数目增多，就会出现运行效率问题，或者至少是资源的利用率下降。
下面的代码示例都以下面的表结构为准：
| Articles 表 | SQL Server 类型 | Oracle 类型 | |
| PK | Id | int (自增) | number(9) (插入时在当前最大值上加1) |
| Author | nvarchar(10) | nvarchar2(10) | |
| Title | nvarchar(50) | nvarchar2(50) | |
| PubTime | datetime | date |
SQL Server / Access 等微软产品中，我们通常的自定义分页有两种思路：
一种是以 ASP.NET Forum 为代表的、“临时表”方法：即在存储过程中建立一个临时表，该临时表包含一个序号字段（1，2，3，....）以及表的主键（其他能够唯一确定一行记录的字段也是可以的）字段。存储过程可能如下：（编号 SS1）
(
@PageIndex int,
@PageSize int,
@TotalRecords out int,
@TotalPages out int
)
AS
DECLARE @PageLowerBound int
DECLARE @PageUpperBound int
-- Set the page bounds
SET @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound + @PageSize + 1
-- Create a temp table to store the select results
CREATE TABLE #tmp
(
RecNo int IDENTITY (1, 1) NOT NULL,
ArticleID int
)
INSERT INTO #tmp
SELECT [ID]
FROM Articles
ORDER BY PubTime DESC
SELECT A.*
FROM Articles A (nolock), #tmp T
WHERE A.ID = T.ArticleID AND
T.RecNo > @PageLowerBound AND
T.RecNo < @PageUpperBound
ORDER BY T.RecNo
GO
另一种可能更适合程序中“拼凑” SQL 语句：用两次 TOP 命令取得我们所要的分页数据，例如：（编号 SS2）
(
SELECT TOP(PageSize) * FROM
(
SELECT TOP (PageSize * PageIndex) *
FROM Articles
ORDER BY PubTime DESC
)
ORDER BY PubTime ASC
)
ORDER BY PubTime DESC
这个的想法就是“掐头去尾”，还有不少分页的方法，这里就不一一列出了。
对于 Oracle 数据库，有几处不同严重妨碍了上面几个方法的实施，比如，Oracle 不支持 TOP 关键字：不过这个好像并不十分严重，因为它提供了 rownum 这个隐式游标，可以实现与 TOP 类似的功能，如：
要写成
rownum 是记录序号（1，2，3...），但有一个比较麻烦的事情是：如果 SQL 语句中有 ORDER BY ... 排序的时候，rownum 居然是先“标号”后排序！这样，这个序号如果不加处理是不合乎使用需求的。
至于临时表，Oracle 的临时表和 SQL Server 的有很大不同，我还没搞懂这个东西，就不妄加揣测了。
国内网站中介绍 Oracle 分页的资料很少，我找到了一个国外站点（www.faqts.com）的一篇 FAQ，根据这篇文章的介绍，可以如下分页：（编号 Ora1）
(
SELECT A.*, rownum r
FROM
(
SELECT *
FROM Articles
ORDER BY PubTime DESC
) A
WHERE rownum <= PageUpperBound
) B
WHERE r > PageLowerBound;
其中蓝色部分可以改为任意的、需要的 SQL SELECT 语句，这点倒是挺方便的。
有兴趣的朋友可以接着谈谈你们的想法和算法，期待中……（为了方便说话，上面三个已经加上编号。大家贴算法时也可以按此序加上编号，方便讨论。）
打印 | 张贴于 2004-09-14 21:17:00 | Tag:暂无标签
留言反馈
版主的这种 ORACLE 分页方式，越到后面应该会越慢的，根据执行计划看COST,BYTES,CPU都逐渐递增的。
to 高材生：应该用版主这种WHERE写法，第一步先要限制ROWNUM，才能尽量减小COST,BYTES,CPU，这在前几页的效能都将是您那种最后才一起写ROWNUM的几十倍，虽然你那么写看上去比较舒服。只有在最后一个分页，计划成本才会和您的那个一致。
oracle中的写法跟楼主的差不多，也可以稍微换个写法：
SELECT * FROM
(
SELECT A.*, rownum r
FROM
(
SELECT *
FROM Articles
ORDER BY PubTime DESC
) A
) B
WHERE r <= PageUpperBound
and r > PageLowerBound;
===========================================
至于sqlserver以及access中，可就慢多了，如果表数据量大的话，估计要用存储过程。否则根本不能用。
写法也如版主那样。
(
SELECT TOP(PageSize) * FROM
(
SELECT TOP (PageSize * PageIndex) *
FROM Articles
ORDER BY PubTime DESC
)
ORDER BY PubTime ASC
)
ORDER BY PubTime DESC
这种GP方法还在传，翻最后一页准错！！（当最后一页的记录不等于PageSize ）
select * from table where rowid not in(select rowid from table where rownum<=200) and rownum<=100;
从201条开始读取100条，不过排序问题就麻烦了！
你那个最主要先是查询的效率问题. 然后才是分页问题.
(select * from tab where seg1>=1000 order by seg1) where rownum<50
??
(
SELECT A.*, rownum r
FROM
(
SELECT *
FROM Articles
ORDER BY PubTime DESC
) A
WHERE rownum <= PageUpperBound
) B
WHERE r > PageLowerBound;
这种方式查大数据的时候每改变一个分页的时候,速度都很慢,建议大数据时候慎用此方法
select * from table where rownum<60
minus
select * from table where rownum<50;
我也这么想过，但问题是我这里是按查询条件进行数据查询
如果有那么大的数据量，就应该像别的办法，比如专门加个字段记录排序位次，
或者间专门的表记录排序位次。我是这么想的。
SELECT TOP pagesize *
FROM articles
WHERE id NOT IN ( SELECT TOP ( pagesize * pageindex ) id FROM articles ORDER BY id DESC )
ORDER BY id DESC
SELECT * FROM
(
SELECT A.*, rownum r
FROM
(
SELECT *
FROM Articles
ORDER BY PubTime DESC
) A
WHERE rownum <= PageUpperBound
) B
WHERE r > PageLowerBound;
我做了一个用session存储记录集的，份页显示零等待。
我在自己的程序中是用这种方法来处理的
临时表的那个处理也有这个意思
不过不太通用
大家也可以把贴出来的想法按此序编个号码，方便说话。
，，最好的办法就是别用分页，，，就像写Blog一样。
你是说 SQL Server 的那个吗？那我没什么可说的。
我想文章里主要想说的是 SQL Server 的临时表法，以及 Oracle 的那个嵌套法，这两个都具有相当的通用性。
哪一个？