难题讨论：对于毫秒级的分页要求你如何应对？做网站的人对速度的追求永远是心头的疼？希望能向高手请教一下大家的分页经验！一、基本要求： 记录总数：50W；
针对某个分类的任意分页：<=50毫秒； 项目组下达了死命令，所有分页列表都要求达到50毫秒以内。目前基本上可以做
0-15毫秒的分页要求。但对于一些要求关联的表，基本上是不可能达到50毫秒的要求，
因此十分头疼，下面是我对毫秒级分页的一些总结：
1、避免表的关联：单表分页目前来看还是最高效的；
2、冗余字段：对于一些常用字段尽量冗余，用空间换时间；
3、聚集索引：一定要加到最关键的字段上，不然也无法达到毫秒级的分页；
还有哪些注意事项，麻烦大家补充一下。谢谢。
针对某个分类的任意分页：<=50毫秒； 项目组下达了死命令，所有分页列表都要求达到50毫秒以内。目前基本上可以做
0-15毫秒的分页要求。但对于一些要求关联的表，基本上是不可能达到50毫秒的要求，
因此十分头疼，下面是我对毫秒级分页的一些总结：
1、避免表的关联：单表分页目前来看还是最高效的；
2、冗余字段：对于一些常用字段尽量冗余，用空间换时间；
3、聚集索引：一定要加到最关键的字段上，不然也无法达到毫秒级的分页；
还有哪些注意事项，麻烦大家补充一下。谢谢。
看看我自定义的缓存
http://blog.csdn.net/comszsoft/archive/2008/07/29/2735009.aspx
一是通过 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 应用的表格的差别有多大。
2 2005 支持在索引中用include关键字加入非键列，形成索引覆盖
当然sql 2005 利用row_number()效率也非常高。我觉得楼主总结得也很好。
只不过很多查询也要注意非聚集索引的建立。50W的记录单表，翻到最后页一般也要50ms.如果采用二分法，可以减少到一半。当时多表关联的话，肯定超50ms了。
http://www.dmblogs.com/nzBlog/article.asp?id=25