本文探讨了在ASP.NET中对大型数据库结果集进行分页的多种方法，对比了临时表、动态SQL及行计数等方案，并分析了各自的优缺点与适用场景。
原文地址：
http://www.codeproject.com/aspnet/PagingLarge.asp
作者：Jasmin Muharemovic
译者：Tony Qu
下载：
PagingTest Solution (C#) - 55.8 Kb
Paging_Procedures SQL script - 2.48 Kb
Paging_LargeTable SQL script - 0.6 Kb
介绍
在Web应用程序中，对一个大数据库结果集进行分页已经是一个家喻户晓的问题了。简单的说，你不希望所有的查询数据显示在一个单独的页面中，所以带有分页 的显示才是更合适的。虽然在传统的asp里这并不是一个简单的任务，但在asp.net中，DataGrid控件把这一过程简化为只有几行代码。因此，在 asp.net中，分页很简单，但是默认的DataGrid分页事件会从数据库中把所有的记录全部读出来放到asp.net web应用程序中。当你的数据在一百万以上的时候，这将引起严重的性能问题（如果你不相信，你可以在你的应用程序中执行一个查询，然后在任务管理器中查看 aspnet_wp.exe的内存消耗情况）这也就是为什么需要自定义分页行为，这样可以保证仅获得当前页需要的数据记录。
在网上有很多关于这个问题的文章和帖子，还有一些成熟的解决方案。我写这篇文章的目的不是向你展示一个可以解决一切问题的存储过程，而是出于优化已有方 法，同时为你提供一个可供测试的应用程序，这样你就可以根据自己的需要进行开发。下文是一个很好的开始，它包含了很多不同的方法，并且给出了一些性能测试 结果
《如何通过Recordset进行分页？》
但是我对上文的大部分内容不是很满意。第一，半数的方法是用了传统的ADO，很明显它们是为“古老”的asp而写的。剩下的一些方法就是SQL Server存储过程，并且其中的一些由于相应时间过慢而无法使用，正如你在文章最后所看到的性能结果一样，但是还是有一些引起了我的注意。
通用化
我决定对其中的三个方法进行仔细的分析，它们是临时表(TempTable)，动态SQL（DynamicSQL）和行计数 (Rowcount)。在下文中，我更愿意把第二个方法称为（升序-降序）Asc-Desc方法。我不认为动态SQL是一个好名字，因为你也可以把动态 SQL逻辑应用于另一个方法中。所有这些存储过程的通病在于，你不得不估计哪些列是你即将要排序的，而不仅仅是估计主键列（PK Columns）而已，这可能导致一系列的问题——对于每个查询来说，你需要通过分页显示，也就是说对于每不同的排序列你必须有许多不同的分页查询，这意 味着你要么给每个排序列做不同的存储过程（无论使用哪种分页方法），也么你必须借助动态SQL的帮助把这个功能放在一个存储过程中。这两个方法对于性能有 微小的影响，但是它增加了可维护性，特别是当你需要使用这个方法显示不同的查询。因此，在本文中我会尝试使用动态SQL对所有的存储过程进行归纳，但是由 于一些原因，我们只能对实现部分的通用性，因此你还是得为复杂查询写独立的存储过程。
允许包括主键列在内的所有排序字段的第二个问题在于，如果那些列没有作适当的索引，那么这些方法一个也帮不上忙。在所有这些方法中，对于一个分页源必须先 做排序，对于大数据表来说，使用非索引列排序的成本是可以忽略不计的。在这种情况下，由于相应时间过长，所有的存储过程都是无法在实际情况下使用的。（相 应的时间各有不同，从几秒钟到几分钟不等，这要根据表的大小和所要获得的第一个记录而定）。其他列的索引会带来额外的不希望出现的性能问题，例如如果你每 天的导入数据很多，它有可能变得很慢。
临时表
首先，我准备先来说一下临时表方法，这是一个广泛被建议使用的解决方案，我在项目中遇到过好几次了，这里有另一篇解释它如何工作的文章，还有一个如何在DataGrid中是用定制化分页（Custom Paging）的例子：
ASP.NET DataGrid分页 第二部分 – 定制化分页
这两篇文章中的方法都是通过把主键数据拷贝到临时表中，然后对主查询做join实现查询优化。下面让我们来看看这个方法的实质：
作者：Jasmin Muharemovic
译者：Tony Qu
下载：
PagingTest Solution (C#) - 55.8 Kb
Paging_Procedures SQL script - 2.48 Kb
Paging_LargeTable SQL script - 0.6 Kb
介绍
在Web应用程序中，对一个大数据库结果集进行分页已经是一个家喻户晓的问题了。简单的说，你不希望所有的查询数据显示在一个单独的页面中，所以带有分页 的显示才是更合适的。虽然在传统的asp里这并不是一个简单的任务，但在asp.net中，DataGrid控件把这一过程简化为只有几行代码。因此，在 asp.net中，分页很简单，但是默认的DataGrid分页事件会从数据库中把所有的记录全部读出来放到asp.net web应用程序中。当你的数据在一百万以上的时候，这将引起严重的性能问题（如果你不相信，你可以在你的应用程序中执行一个查询，然后在任务管理器中查看 aspnet_wp.exe的内存消耗情况）这也就是为什么需要自定义分页行为，这样可以保证仅获得当前页需要的数据记录。
在网上有很多关于这个问题的文章和帖子，还有一些成熟的解决方案。我写这篇文章的目的不是向你展示一个可以解决一切问题的存储过程，而是出于优化已有方 法，同时为你提供一个可供测试的应用程序，这样你就可以根据自己的需要进行开发。下文是一个很好的开始，它包含了很多不同的方法，并且给出了一些性能测试 结果
《如何通过Recordset进行分页？》
但是我对上文的大部分内容不是很满意。第一，半数的方法是用了传统的ADO，很明显它们是为“古老”的asp而写的。剩下的一些方法就是SQL Server存储过程，并且其中的一些由于相应时间过慢而无法使用，正如你在文章最后所看到的性能结果一样，但是还是有一些引起了我的注意。
通用化
我决定对其中的三个方法进行仔细的分析，它们是临时表(TempTable)，动态SQL（DynamicSQL）和行计数 (Rowcount)。在下文中，我更愿意把第二个方法称为（升序-降序）Asc-Desc方法。我不认为动态SQL是一个好名字，因为你也可以把动态 SQL逻辑应用于另一个方法中。所有这些存储过程的通病在于，你不得不估计哪些列是你即将要排序的，而不仅仅是估计主键列（PK Columns）而已，这可能导致一系列的问题——对于每个查询来说，你需要通过分页显示，也就是说对于每不同的排序列你必须有许多不同的分页查询，这意 味着你要么给每个排序列做不同的存储过程（无论使用哪种分页方法），也么你必须借助动态SQL的帮助把这个功能放在一个存储过程中。这两个方法对于性能有 微小的影响，但是它增加了可维护性，特别是当你需要使用这个方法显示不同的查询。因此，在本文中我会尝试使用动态SQL对所有的存储过程进行归纳，但是由 于一些原因，我们只能对实现部分的通用性，因此你还是得为复杂查询写独立的存储过程。
允许包括主键列在内的所有排序字段的第二个问题在于，如果那些列没有作适当的索引，那么这些方法一个也帮不上忙。在所有这些方法中，对于一个分页源必须先 做排序，对于大数据表来说，使用非索引列排序的成本是可以忽略不计的。在这种情况下，由于相应时间过长，所有的存储过程都是无法在实际情况下使用的。（相 应的时间各有不同，从几秒钟到几分钟不等，这要根据表的大小和所要获得的第一个记录而定）。其他列的索引会带来额外的不希望出现的性能问题，例如如果你每 天的导入数据很多，它有可能变得很慢。
临时表
首先，我准备先来说一下临时表方法，这是一个广泛被建议使用的解决方案，我在项目中遇到过好几次了，这里有另一篇解释它如何工作的文章，还有一个如何在DataGrid中是用定制化分页（Custom Paging）的例子：
ASP.NET DataGrid分页 第二部分 – 定制化分页
这两篇文章中的方法都是通过把主键数据拷贝到临时表中，然后对主查询做join实现查询优化。下面让我们来看看这个方法的实质：
CREATE
TABLE
#
Temp
(
ID int IDENTITY PRIMARY KEY ,
PK /* here goes PK type */
)
INSERT INTO # Temp SELECT PK FROM Table ORDER BY SortColumn
SELECT
FROM
Table
JOIN
#
Temp
temp
ON
Table
.PK
=
temp
.PK
ORDER
BY
temp
.ID
WHERE ID > @StartRow AND ID < @EndRow
ID int IDENTITY PRIMARY KEY ,
PK /* here goes PK type */
)
INSERT INTO # Temp SELECT PK FROM Table ORDER BY SortColumn
SELECT
FROM
Table
JOIN
#
Temp
temp
ON
Table
.PK
=
temp
.PK
ORDER
BY
temp
.ID WHERE ID > @StartRow AND ID < @EndRow
扫一扫
2154
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
