在web开发中经常碰到排序，可能有人有这样的想法：
1，排序是什么时候排序，是在执行sql语句前完成排序功能，还是最后？
2，排序对sql语句性能有影响吗？
3，在排序中建立索引有好处吗？
这段时间，在优化系统时，也碰到类似的问题，今天我们来讨论一下排序这个问题，
1，首先我们看看什么时候排序
执行以下的sql语句：
SELECT * FROM [dbo].[[[zping.com]]]]] where laststepid='402882ed0ea1c940010ea2332879007f' order by workflowid执行计划：
这里发现，sql server中排序是在数据找出来以后在进行排序的，
如果我们在前面加上一个top 2 *限制条件，那”Sort“和“Top N ”谁先谁后啦。执行了一下，
发现，”Sort“和“Top N ”合并成了一个“Top N Sort”操作，在排序时，就直接选出数据了
顺序：
排序是“top N”前执行，查出全部数据后执行的。
2，排序对sql语句性能有影响吗？
1，上面刚刚看到，但通过索引选出来的数据比较少时，排序是很快的。对性能没有影响。uju
2， 但如果查询没有条件，如下列sql
SELECT TOP (10*(100-1)) ID FROM [dbo].[[[zping.com]]]]] ORDER BY workflowid DESC如果此时workflowid没有索引，该查询速度会很慢：
为何：因为这时数据库不知道workflowid的排序顺序，只有进行表扫描，取出全部表数据，才能按workflowid来排序，再进行排序后取前几行数据。
如果这时在workflowid建立有索引，优化器就可以通过索引排序好的RID，取出990行数据，这时执行计划里就不会有"sort"操作，
因为索引已经排好序了。
但对其他sql有影响吗？这次我们在优化分页功能是就发现排序很花费时间。为何啦？，我们先看看一个常用排序sql
SELECT TOP 20 * FROM [dbo].[[[zping.com]]]]] WHERE (ID IN (SELECT TOP (10*(10000-1)) ID FROM [dbo].[[[zping.com]]]]] ORDER BY workflowid )) ORDER BY workflowid DESC
这里的：id为唯一索引，workflowid为非唯一索引，执行计划如下：
这里发现：排序很花时间，占到了44%的开销了。
为何我在workflowid建立了索引，还是慢啦？
SQL Server 2005 分页比 2000的确提高不少，可以使用 row_number()函数来处理。
先看看这个分页函数的效率。新建一个表[[zping.com]]
CREATE TABLE [dbo].[[[zping.com]]]]]( [id] [varchar](32) NOT NULL, [wwid] [varchar](32) NULL, [laid] [varchar](32) NULL, [cupid] [varchar](32) NULL, [isreceived] [int] NULL, [issited] [int] NULL, [ised] [int] NULL, [isfhed] [int] NULL )
导入该表数据有70万，取60-80条间的20条数据，在id建立唯一索引
select * from (select *, row_number() over (order by id) scn from [dbo].[[[zping.com]]]]] ) t where scn<=80 and scn>60sql server统计信息：
表 '[[zping.com]]'。扫描计数 1，逻辑读取 83 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。这里看到其逻辑读才83次，数据效率很高
我们把取100000到100000-20条之间的数据
select * from (select *, row_number() over (order by id) scn from [dbo].[[[zping.com]]]]] ) t where scn<100000 and scn>100000-20sql server统计信息：
(19 行受影响) 表 '[[zping.com]]'。扫描计数 1，逻辑读取 100740 次，物理读取 259 次，预读 2026 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。这里发现取100000到100000-20条之间的数据，花费了逻辑读取 100740 次，是上一个几千倍。同样是取20条数据，差距为何
这么大啊：我们对比一下执行计划：
查看一下取60-80行的执行计划：
1，在开始取数据时的索引扫描同样是取的“id索引”的“实际行数”是80行，在通过嵌套循环取出这个80行数据的全部字段。
2，”序列射影“是“[Expr1004] = 标量运算符(row_number)”，说明，在选出来的list中增加虚拟列序号如(1,2,3......)
3，第“筛选器”这个谓词操作时他的运作是“[Expr1004]>(60) AND [Expr1004]<=(80)”，取出20行数据
实际上：这时过程中只去了80行数据，再去取20行数据
看看100000到100000-20条之间的数据执行计划
执行计划和上面的一样：
细微差别：
1，在开始取数据“id索引”的“实际行数”是10万行
2，在筛选器中谓词为“[Expr1004]>(99980) AND [Expr1004]<(100000)”
分页技术总结：
1， row_number()函数，只有在数据选择出来以后再加上的虚拟列，选择的时候是不知道编号的。
2， 要取出非索引的数据，数据库要到表里把预先要的数据全部取出来，行越多逻辑读也也越多。
摘录自http://www.cnblogs.com/zping/archive/2008/07/21/1247718.html