Paging of Large Resultsets in ASP.NET中对几种常见的分页方式做了比较感觉写得不错，前段时间因为要做asp.net分页，就想到了这篇文章，但经过测试后发现不少问题，虽然按照留言的介绍和自己的努力做了些修改，最终还是放弃了。
今天在逛博客园的时候发现了这篇文章：优化后的通用分页存储过程(已更新) ，觉得有必要说说这个Sp的问题了，这里没有别的意思，只是想阐述下我对这个SP的一点理解，希望对打算使用这个SP的人一点提示：
1)如果PK是GUID怎么办？对PK排序没有任何意义
2)如果要排序的字段中含有DESC或者ASC字眼怎么办？
这个只要看看MS的Demo数据库Northwind就知道了
select A.Name,B.Name from syscolumns A
inner join sysobjects B
on A.id=B.id
where A.name like '%desc%'
(FieldName TableName
CustomerDesc CustomerDemographics
RegionDescription Region
TerritoryDescription Territories
Description Categories)
如果打算使用该SP，最好把字段和排序标示（DESC，ASC）分开；
3)忽视了@Sort字符串中首字母为空格的问题；
4)如果Fields中字段名是alias怎么办？
5)如果要排序的字段为组合字段怎么办？比如"Employees.LastName +' '+ Employees.FirstName DESC"
这里放个简单的例子，可以发现其中的很多问题（试着按不同的字段进行排序）:
exec Paging_RowCount
@Tables='Orders INNER JOIN
Customers ON Orders.CustomerID = Customers.CustomerID INNER JOIN
Employees ON Orders.EmployeeID = Employees.EmployeeID INNER JOIN
Shippers ON Orders.ShipVia = Shippers.ShipperID',
@PK='Orders.OrderID',
@Fields='Orders.OrderID, Customers.CompanyName,
Employees.LastName +''''+ Employees.FirstName AS [Employee FullName],
Orders.OrderDate, Orders.RequiredDate, Orders.ShippedDate,
Shippers.CompanyName AS ShipVia, Orders.Freight, Orders.ShipName',
@PageSize=25,
@Sort=" Customers.CompanyName DESC"
P.S.
TOPN 子句与SET ROWCOUNTN 之对比 2001年5月21日
今天在逛博客园的时候发现了这篇文章：优化后的通用分页存储过程(已更新) ，觉得有必要说说这个Sp的问题了，这里没有别的意思，只是想阐述下我对这个SP的一点理解，希望对打算使用这个SP的人一点提示：
1)如果PK是GUID怎么办？对PK排序没有任何意义
2)如果要排序的字段中含有DESC或者ASC字眼怎么办？
这个只要看看MS的Demo数据库Northwind就知道了
select A.Name,B.Name from syscolumns A
inner join sysobjects B
on A.id=B.id
where A.name like '%desc%'
(FieldName TableName
CustomerDesc CustomerDemographics
RegionDescription Region
TerritoryDescription Territories
Description Categories)
如果打算使用该SP，最好把字段和排序标示（DESC，ASC）分开；
3)忽视了@Sort字符串中首字母为空格的问题；
4)如果Fields中字段名是alias怎么办？
5)如果要排序的字段为组合字段怎么办？比如"Employees.LastName +' '+ Employees.FirstName DESC"
这里放个简单的例子，可以发现其中的很多问题（试着按不同的字段进行排序）:
exec Paging_RowCount
@Tables='Orders INNER JOIN
Customers ON Orders.CustomerID = Customers.CustomerID INNER JOIN
Employees ON Orders.EmployeeID = Employees.EmployeeID INNER JOIN
Shippers ON Orders.ShipVia = Shippers.ShipperID',
@PK='Orders.OrderID',
@Fields='Orders.OrderID, Customers.CompanyName,
Employees.LastName +''''+ Employees.FirstName AS [Employee FullName],
Orders.OrderDate, Orders.RequiredDate, Orders.ShippedDate,
Shippers.CompanyName AS ShipVia, Orders.Freight, Orders.ShipName',
@PageSize=25,
@Sort=" Customers.CompanyName DESC"
P.S.
TOPN 子句与SET ROWCOUNTN 之对比 2001年5月21日
问：为了从查询中返回指定数量的行，使用 TOPN 子句比使用SET ROWCOUNTN 语句要快吗？
答：在正确进行了索引的情况下，TOP N 子句和SET ROWCOUNT N 语句是一样快的，但是如果数据未经过排序，TOP N 要快一些。在输入未排序的情况下，TOP N 操作时使用一个经过排序的小的中间临时表，而且操作时仅仅替换该表的最后一行。如果输入是近似排序的，TOP N 引擎必须删除或插入最后行，但只需几次操作即可。近似排序意味着您正在处理的堆集在初始构建时可进行有序的插入操作，并且不需要进行很多的更新、删除、向前移动指针等操作。
排序一个近似排序的堆集比排序一个巨大的表要更有效率。在一次测试中，使用TOP N 来对一个由无序插入操作构建的并且含有同样的行数的表进行排序，发现TOP N 的效率也不高。通常，在进行过索引和未进行过索引的情况下，I/O时间都是一样的；但是如果没有进行过索引，SQL Server 必须要进行一次全表扫描。处理器时间和实耗时间说明近似排序的堆集要更有效率一些。但I/O时间是相同的，因为不管怎样SQL Server都要读取所有的行。
