分页算法，还可以更好
分页算法，是Web开发人员很关心的一个问题，几乎每个数据库相关的应用都要涉及到分页算法，有很多人写过这方面的文档，似乎没有什么好讨论的了；但实际上换一种数据的表现形式，就可以采用一种更好的分页算法，那我们现在就看看还能不能做得更好。
先说说已有的一些方法。
一是通过 DataGrid 分页，这种方式最简单，但效率不高，需要读取所需数据前面的所有数据。
二是通过指定起始记录和记录数的 DbDataAdapter.Fill 来填充 DataSet 的分页方式，这种方式也简单，但同样效率不高，也需要读取所需数据前面的所有数据。
三是通过多个 select top 和多次排序，从表的中间选取需要的记录；为了使相邻页的数据不重复，需要使用 not in，会导致在选择大数据量的表格的尾部数据时，数据库的性能会有很大的降低。
假设我们换一种表格的展现形式，就以传统的 C/S 应用下的带滚动条的 Grid 展现方式为例；其实这种方式才是数据库表格最合适的展现方式，而 Web 应用下常用的 1,2,3....的页码连接方式或上一页、下一页按钮的页码浏览条方式，都是不得已而为之，因为不能通过简单的技术，在 Web 应用下实现带滚动条的 Grid。
数据库的表格都是带有主键的，以区分表格中不同的记录；用户界面上的 Grid 里的数据从逻辑上也是有主键的，否则数据会有歧义，但大多数的应用，没有设置，也无法知道所读出数据的主键；即使少数应用设置了，也知道所读数据的主键，但并没有将其应用到分页中；其实只要知道了所读数据的主键，就可以非常容易的进行分页。
首页的算法很简单
select top 页大小 * from 表名 order by 主键
对于带滚动条的表格，数据是一页一页顺序滚动，即使拖动滚动条，也可以一页页滚动到所选的位置，当拖动到一个新页时的算法为
select top 页大小 * from 表名 where 主键 > 上一页末记录的主键 order by 主键
如果采用了缓存的方式，所有的数据都只需要下载一次，只有滚动到尾部时，才下载新的数据。
这种算法要求知道 Grid 中数据的主键，并将主键的数据应用到分页；对于多主键和排序的表格，算法是一样的，只是语句复杂了一些。不但可以从首页开始，也可以从末页开始，向前翻滚。
这个算法的性能没有问题，对于不论多大的表，选择那个位置的记录都是一样的，比较适合于用首页、上一页、下一页和末页的分页选择方式，更适合于带滚动条的 Grid ；不适合于指定页码的分页。
采用该算法的带滚动条的 Grid 可以参考我们的演示 www.BizStruct.cn。
请您在提出疑问时，先考虑两点，否则可能认识不到这个算法和我们系统结合的优势：
第一：传统的 C/S 应用的表格和Web上的分页表格，谁更便利。
第一，我们实现的带滚动条的表格，和传统的 C/S 应用的表格的差别有多大。
对回复的解释：
有的回复提出无法实现“跳转到xx页”这样的操作。
可我们想想，在 C/S 的应用环境下，如果谁用这种页面跳转的方式，大家肯定会觉得怪异。
而我们实现的带滚动条的 Grid 在局域网环境下，速度几乎和以前的 C/S 应用差不多，在广域网的情况下，速度也很快。
Web 应用的“跳转到XX页的操作”实际上是不得已而为之，如果能实现 传统的 C/S 应用的Grid，为什么还要用这个呢？
先说说已有的一些方法。
一是通过 DataGrid 分页，这种方式最简单，但效率不高，需要读取所需数据前面的所有数据。
二是通过指定起始记录和记录数的 DbDataAdapter.Fill 来填充 DataSet 的分页方式，这种方式也简单，但同样效率不高，也需要读取所需数据前面的所有数据。
三是通过多个 select top 和多次排序，从表的中间选取需要的记录；为了使相邻页的数据不重复，需要使用 not in，会导致在选择大数据量的表格的尾部数据时，数据库的性能会有很大的降低。
假设我们换一种表格的展现形式，就以传统的 C/S 应用下的带滚动条的 Grid 展现方式为例；其实这种方式才是数据库表格最合适的展现方式，而 Web 应用下常用的 1,2,3....的页码连接方式或上一页、下一页按钮的页码浏览条方式，都是不得已而为之，因为不能通过简单的技术，在 Web 应用下实现带滚动条的 Grid。
数据库的表格都是带有主键的，以区分表格中不同的记录；用户界面上的 Grid 里的数据从逻辑上也是有主键的，否则数据会有歧义，但大多数的应用，没有设置，也无法知道所读出数据的主键；即使少数应用设置了，也知道所读数据的主键，但并没有将其应用到分页中；其实只要知道了所读数据的主键，就可以非常容易的进行分页。
首页的算法很简单
select top 页大小 * from 表名 order by 主键
对于带滚动条的表格，数据是一页一页顺序滚动，即使拖动滚动条，也可以一页页滚动到所选的位置，当拖动到一个新页时的算法为
select top 页大小 * from 表名 where 主键 > 上一页末记录的主键 order by 主键
如果采用了缓存的方式，所有的数据都只需要下载一次，只有滚动到尾部时，才下载新的数据。
这种算法要求知道 Grid 中数据的主键，并将主键的数据应用到分页；对于多主键和排序的表格，算法是一样的，只是语句复杂了一些。不但可以从首页开始，也可以从末页开始，向前翻滚。
这个算法的性能没有问题，对于不论多大的表，选择那个位置的记录都是一样的，比较适合于用首页、上一页、下一页和末页的分页选择方式，更适合于带滚动条的 Grid ；不适合于指定页码的分页。
采用该算法的带滚动条的 Grid 可以参考我们的演示 www.BizStruct.cn。
请您在提出疑问时，先考虑两点，否则可能认识不到这个算法和我们系统结合的优势：
第一：传统的 C/S 应用的表格和Web上的分页表格，谁更便利。
第一，我们实现的带滚动条的表格，和传统的 C/S 应用的表格的差别有多大。
对回复的解释：
有的回复提出无法实现“跳转到xx页”这样的操作。
可我们想想，在 C/S 的应用环境下，如果谁用这种页面跳转的方式，大家肯定会觉得怪异。
而我们实现的带滚动条的 Grid 在局域网环境下，速度几乎和以前的 C/S 应用差不多，在广域网的情况下，速度也很快。
Web 应用的“跳转到XX页的操作”实际上是不得已而为之，如果能实现 传统的 C/S 应用的Grid，为什么还要用这个呢？
浙公网安备 33010602011771号
Feedback
这个未免太勉强了吧，我要拖动到第10页，你也要从1开始1，2，3....
其不是更没什么性能可谈的！！！
回复
这种需求是很常见的啊。 回复
如果以非主键字段为排序字段，这种分页算法是一样的。只是将非主键字段作为第一个排序字段，主键字段作为其他排序字段。
@Bear.sTaR{R}
@蔡克伦
在 C/S 应用下，如果谁用这种页面跳转的方式，大家肯定会觉得怪异。
而我们实现的带滚动条的 Grid 在局域网环境下，速度几乎和以前的 C/S 应用差不多，在广域网的情况下，速度也很快。
Web 应用的“跳转到XX页的操作”实际上是不得已而为之，如果能实现 传统的 C/S 应用的Grid，为什么还要用这个呢。 回复
很佩服你的勇气 回复
就是面临海量数据的时候应该怎么办
在大多数情况下，在一个大型项目中，比如，列表里显示的是一个市男性市民的资料在gridview（或类似，当然你不要说为什么这个查询这么变态，在需求面前就是这样）中，50万左右的数据，可想而知，iis肯定是要挂了，我记得当初我测试10万条的时候就已经不行了。 回复
我们讨论的是分页算法，50万的数据肯定不会一次下载；如果一页一页下载，IIS是不会有问题的；数据下载是后台的，自动的，不需要操作的。
我们的解决方案正好适合你的需求，而其他的分页方式都不行。
回复
存在的就是合理的！！！ 回复
至于楼主说的方法,要有缓存才行?而且对主键也有一定依赖,个人觉得在特定的业务下可以用此分页算法,但并不像目前的几种那么有普遍性(虽然普遍性也没有太多.) 回复
如果都是这样想的话，社会就不会有进步，技术也不会有进步。 回复
http://hertcloud.cnblogs.com/
我想我这里的存储过程是你需要的东西
还有好像分页算法和使用什么控件没有多大的联系吧
回复就你所说在大表格的尾部的性能比 not in 高一倍，可你和自己的第一页查询的性能比了吗，估计差一个数量级；可我们的算法所有页的查询和你的第一页查询的性能基本一样。 回复