SQLServer 大数据查询分析

在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>60

  sql 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-20

 sql 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