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都要读取所有的行。 

本文转自RubyPdf 的中文博客博客园博客，原文链接：http://www.cnblogs.com/hardrock/archive/2006/01/17/319155.html，如需转载请自行联系原作http://www.cnblogs.com/hardrock/archive/2006/05/17/402654.html