如何提升SQL的执行效率

1、因情制宜，创建“适当”的索引

创建“适当”的索引是实现查询优化的首要前提。

索引（index）是除表以外另外一重要的、用户定义的存储在物理介质上的数据结构。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得愈来愈大，使用“适当”的索引的效果就愈来愈明显。注意，在这句话中，咱们用了“适当”这个词，这是由于，若是使用索引时不认真考虑其实现过程，索引既能够提升也会破坏数据库的工做性能。

（一）深刻浅出理解索引结构

实际上，您能够把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：汇集索引（clustered index，也称聚类索引、簇集索引）和非汇集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，咱们举例来讲明一下汇集索引和非汇集索引的区别：

其实，咱们的汉语字典的正文自己就是一个汇集索引。好比，咱们要查“安”字，就会很天然地翻开字典的前几页，由于“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就天然地排在字典的前部。若是您翻完了全部以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；一样的，若是查“张”字，那您也会将您的字典翻到最后部分，由于“张”的拼音是“zhang”。也就是说，字典的正文部分自己就是一个目录，您不须要再去查其余目录来找到您须要找的内容。

咱们把这种正文内容自己就是一种按照必定规则排列的目录称为“汇集索引”。

若是您认识某个字，您能够快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而须要去根据“偏旁部首”查到您要找的字，而后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并非真正的正文的排序方法，好比您查“张”字，咱们能够看到在查部首以后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码倒是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并非真正的分别位于“张”字的上下方，如今您看到的连续的“驰、张、弩”三字实际上就是他们在非汇集索引中的排序，是字典正文中的字在非汇集索引中的映射。咱们能够经过这种方式来找到您所须要的字，但它须要两个过程，先找到目录中的结果，而后再翻到您所须要的页码。

咱们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非汇集索引”。

经过以上例子，咱们能够理解到什么是“汇集索引”和“非汇集索引”。

进一步引伸一下，咱们能够很容易的理解：每一个表只能有一个汇集索引，由于目录只能按照一种方法进行排序。

（二）什么时候使用汇集索引或非汇集索引

下面的表总结了什么时候使用汇集索引或非汇集索引（很重要）。

动做描述
 使用汇集索引
 使用非汇集索引
 
列常常被分组排序
 应
 应
 
返回某范围内的数据
 应
 不该
 
一个或极少不一样值
 不该
 不该
 
小数目的不一样值
 应
 不该
 
大数目的不一样值
 不该
 应
 
频繁更新的列
 不该
 应
 
外键列
 应
 应
 
主键列
 应
 应
 
频繁修改索引列
 不该
 应
 

事实上，咱们能够经过前面汇集索引和非汇集索引的定义的例子来理解上表。如：返回某范围内的数据一项。好比您的某个表有一个时间列，刚好您把聚合索引创建在了该列，这时您查询2004年1月1日至2004年10月1日之间的所有数据时，这个速度就将是很快的，由于您的这本字典正文是按日期进行排序的，聚类索引只须要找到要检索的全部数据中的开头和结尾数据便可；而不像非汇集索引，必须先查到目录中查到每一项数据对应的页码，而后再根据页码查到具体内容。

（三）结合实际，谈索引使用的误区

理论的目的是应用。虽然咱们刚才列出了什么时候应使用汇集索引或非汇集索引，但在实践中以上规则却很容易被忽视或不能根据实际状况进行综合分析。下面咱们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于你们掌握索引创建的方法。

一、主键就是汇集索引

这种想法笔者认为是极端错误的，是对汇集索引的一种浪费。虽然SQL SERVER默认是在主键上创建汇集索引的。

一般，咱们会在每一个表中都创建一个ID列，以区分每条数据，而且这个ID列是自动增大的，步长通常为1。咱们的这个办公自动化的实例中的列Gid就是如此。此时，若是咱们将这个列设为主键，SQL SERVER会将此列默认为汇集索引。这样作有好处，就是可让您的数据在数据库中按照ID进行物理排序，但笔者认为这样作意义不大。

显而易见，汇集索引的优点是很明显的，而每一个表中只能有一个汇集索引的规则，这使得汇集索引变得更加珍贵。

从咱们前面谈到的汇集索引的定义咱们能够看出，使用汇集索引的最大好处就是可以根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，由于ID号是自动生成的，咱们并不知道每条记录的ID号，因此咱们很难在实践中用ID号来进行查询。这就使让ID号这个主键做为汇集索引成为一种资源浪费。其次，让每一个ID号都不一样的字段做为汇集索引也不符合“大数目的不一样值状况下不该创建聚合索引”规则；固然，这种状况只是针对用户常常修改记录内容，特别是索引项的时候会负做用，但对于查询速度并无影响。

在办公自动化系统中，不管是系统首页显示的须要用户签收的文件、会议仍是用户进行文件查询等任何状况下进行数据查询都离不开字段的是“日期”还有用户自己的“用户名”。

一般，办公自动化的首页会显示每一个用户还没有签收的文件或会议。虽然咱们的where语句能够仅仅限制当前用户还没有签收的状况，但若是您的系统已创建了很长时间，而且数据量很大，那么，每次每一个用户打开首页的时候都进行一次全表扫描，这样作意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样作只能徒增数据库的开销而已。事实上，咱们彻底可让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，经过“日期”这个字段来限制表扫描，提升查询速度。若是您的办公自动化系统已经创建的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。

在这里之因此提到“理论上”三字，是由于若是您的汇集索引仍是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即便您在“日期”这个字段上创建的索引（非聚合索引）。下面咱们就来看一下在1000万条数据量的状况下各类查询的速度表现（3个月内的数据为25万条）：

（1）仅在主键上创建汇集索引，而且不划分时间段：

Select gid,fariqi,neibuyonghu,title from tgongwen

用时：128470毫秒（即：128秒）

（2）在主键上创建汇集索引，在fariq上创建非汇集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：53763毫秒（54秒）

（3）将聚合索引创建在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：2423毫秒（2秒）

虽然每条语句提取出来的都是25万条数据，各类状况的差别倒是巨大的，特别是将汇集索引创建在日期列时的差别。事实上，若是您的数据库真的有1000万容量的话，把主键创建在ID列上，就像以上的第一、2种状况，在网页上的表现就是超时，根本就没法显示。这也是我摒弃ID列做为汇集索引的一个最重要的因素。

得出以上速度的方法是：在各个select语句前加：declare @d datetime

set @d=getdate()

并在select语句后加：

select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

二、只要创建索引就能显著提升查询速度

事实上，咱们能够发现上面的例子中，第二、3条语句彻底相同，且创建索引的字段也相同；不一样的仅是前者在fariqi字段上创建的是非聚合索引，后者在此字段上创建的是聚合索引，但查询速度却有着天壤之别。因此，并不是是在任何字段上简单地创建索引就能提升查询速度。

从建表的语句中，咱们能够看到这个有着1000万数据的表中fariqi字段有5003个不一样记录。在此字段上创建聚合索引是再合适不过了。在现实中，咱们天天都会发几个文件，这几个文件的发文日期就相同，这彻底符合创建汇集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，咱们创建“适当”的聚合索引对于咱们提升查询速度是很是重要的。

三、把全部须要提升查询速度的字段都加进汇集索引，以提升查询速度

上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户自己的“用户名”。既然这两个字段都是如此的重要，咱们能够把他们合并起来，创建一个复合索引（compound index）。

不少人认为只要把任何字段加进汇集索引，就能提升查询速度，也有人感到迷惑：若是把复合的汇集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，咱们来看一下如下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合汇集索引的起始列，用户名neibuyonghu排在后列）

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' 

查询速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' and neibuyonghu='办公室'

查询速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu='办公室'

查询速度：60280毫秒

从以上试验中，咱们能够看到若是仅用汇集索引的起始列做为查询条件和同时用到复合汇集索引的所有列的查询速度是几乎同样的，甚至比用上所有的复合索引列还要略快（在查询结果集数目同样的状况下）；而若是仅用复合汇集索引的非起始列做为查询条件的话，这个索引是不起任何做用的。固然，语句一、2的查询速度同样是由于查询的条目数同样，若是复合索引的全部列都用上，并且查询结果少的话，这样就会造成“索引覆盖”，于是性能能够达到最优。同时，请记住：不管您是否常用聚合索引的其余列，但其前导列必定要是使用最频繁的列。

（四）其余书上没有的索引使用经验总结

一、用聚合索引比用不是聚合索引的主键速度快

下面是实例语句：（都是提取25万条数据）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

使用时间：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

使用时间：4470毫秒

这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。

二、用聚合索引比用通常的主键做order by时速度快，特别是在小数据量状况下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

用时：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

用时：18843

这里，用聚合索引比用通常的主键做order by时，速度快了3/10。事实上，若是数据量很小的话，用汇集索引做为排序列要比使用非汇集索引速度快得明显的多；而数据量若是很大的话，如10万以上，则两者的速度差异不明显。

三、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减小，而不管聚合索引使用了多少个

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1'

用时：6343毫秒（提取100万条） 

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-6-6'

用时：3170毫秒（提取50万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

用时：3326毫秒（和上句的结果如出一辙。若是采集的数量同样，那么用大于号和等于号是同样的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' and fariqi<'2004-6-6'

用时：3280毫秒

4 、日期列不会由于有分秒的输入而减慢查询速度

下面的例子中，共有100万条数据，2004年1月1日之后的数据有50万条，但只有两个不一样的日期，日期精确到日；以前有数据50万条，有5000个不一样的日期，日期精确到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' order by fariqi

用时：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<'2004-1-1' order by fariqi

用时：6453毫秒

（五）其余注意事项

“水可载舟，亦可覆舟”，索引也同样。索引有助于提升检索性能，但过多或不当的索引也会致使系统低效。由于用户在表中每加进一个索引，数据库就要作更多的工做。过多的索引甚至会致使索引碎片。

因此说，咱们要创建一个“适当”的索引体系，特别是对聚合索引的建立，更应精益求精，以使您的数据库能获得高性能的发挥。

固然，在实践中，做为一个尽职的数据库管理员，您还要多测试一些方案，找出哪一种方案效率最高、最为有效。

 

2、改善SQL语句

不少人不知道SQL语句在SQL SERVER中是如何执行的，他们担忧本身所写的SQL语句会被SQL SERVER误解。好比：

select * from table1 where name='zhangsan' and tID > 10000

和执行:

select * from table1 where tID > 10000 and name='zhangsan'

一些人不知道以上两条语句的执行效率是否同样，由于若是简单的从语句前后上看，这两个语句的确是不同，若是tID是一个聚合索引，那么后一句仅仅从表的10000条之后的记录中查找就好了；而前一句则要先从全表中查找看有几个name='zhangsan'的，然后再根据限制条件条件tID>10000来提出查询结果。

事实上，这样的担忧是没必要要的。SQL SERVER中有一个“查询分析优化器”，它能够计算出where子句中的搜索条件并肯定哪一个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器能够根据where子句自动的进行查询优化，但你们仍然有必要了解一下“查询优化器”的工做原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。

在查询分析阶段，查询优化器查看查询的每一个阶段并决定限制须要扫描的数据量是否有用。若是一个阶段能够被用做一个扫描参数（SARG），那么就称之为可优化的，而且能够利用索引快速得到所需数据。

SARG的定义：用于限制搜索的一个操做，由于它一般是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND链接。形式以下：

列名 操做符 <常数 或 变量>

或

<常数 或 变量> 操做符列名

列名能够出如今操做符的一边，而常数或变量出如今操做符的另外一边。如：

Name=’张三’

价格>5000

5000<价格

Name=’张三’ and 价格>5000

若是一个表达式不能知足SARG的形式，那它就没法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否知足WHERE子句中的全部条件。因此一个索引对于不知足SARG形式的表达式来讲是无用的。

介绍完SARG后，咱们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不一样的经验：

一、Like语句是否属于SARG取决于所使用的通配符的类型

如：name like ‘张%’ ，这就属于SARG

而：name like ‘%张’ ,就不属于SARG。

缘由是通配符%在字符串的开通使得索引没法使用。

二、or 会引发全表扫描

Name=’张三’ and 价格>5000 符号SARG，而：Name=’张三’ or 价格>5000 则不符合SARG。使用or会引发全表扫描。

三、非操做符、函数引发的不知足SARG形式的语句

不知足SARG形式的语句最典型的状况就是包括非操做符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不知足SARG形式的例子：

ABS(价格)<5000

Name like ‘%三’

有些表达式，如：

WHERE 价格*2>5000

SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：

WHERE 价格>2500/2

但咱们不推荐这样使用，由于有时SQL SERVER不能保证这种转化与原始表达式是彻底等价的。

四、IN 的做用至关与OR

语句：

Select * from table1 where tid in (2,3)

和

Select * from table1 where tid=2 or tid=3

是同样的，都会引发全表扫描，若是tid上有索引，其索引也会失效。

五、尽可能少用NOT

六、exists 和 in 的执行效率是同样的

不少资料上都显示说，exists要比in的执行效率要高，同时应尽量的用not exists来代替not in。但事实上，我试验了一下，发现两者不管是前面带不带not，两者之间的执行效率都是同样的。由于涉及子查询，咱们试验此次用SQL SERVER自带的pubs数据库。运行前咱们能够把SQL SERVER的statistics I/O状态打开。

（1）select title,price from titles where title_id in (select title_id from sales where qty>30)

该句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

    

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)

第二句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

咱们今后能够看到用exists和用in的执行效率是同样的。

七、用函数charindex()和前面加通配符%的LIKE执行效率同样

前面，咱们谈到，若是在LIKE前面加上通配符%，那么将会引发全表扫描，因此其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提高，经我试验，发现这种说明也是错误的：

select gid,title,fariqi,reader from tgongwen where charindex('刑侦支队',reader)>0 and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

select gid,title,fariqi,reader from tgongwen where reader like '%' + '刑侦支队' + '%' and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

八、union并不绝对比or的执行效率高

咱们前面已经谈到了在where子句中使用or会引发全表扫描，通常的，我所见过的资料都是推荐这里用union来代替or。事实证实，这种说法对于大部分都是适用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or gid>9990000

用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' 

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。

看来，用union在一般状况下比用or的效率要高的多。

但通过试验，笔者发现若是or两边的查询列是同样的话，那么用union则反倒和用or的执行速度差不少，虽然这里union扫描的是索引，而or扫描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or fariqi='2004-2-5'

用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' 

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where  fariqi='2004-2-5'

用时：11640毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。

九、字段提取要按照“需多少、提多少”的原则，避免“select *”

咱们来作一个试验：

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用时：4673毫秒

select top 10000 gid,fariqi,title from tgongwen order by gid desc

用时：1376毫秒

select top 10000 gid,fariqi from tgongwen order by gid desc

用时：80毫秒

由此看来，咱们每少提取一个字段，数据的提取速度就会有相应的提高。提高的速度还要看您舍弃的字段的大小来判断。

十、count(*)不比count(字段)慢

某些资料上说：用*会统计全部列，显然要比一个世界的列名效率低。这种说法实际上是没有根据的。咱们来看：

select count(*) from Tgongwen

用时：1500毫秒

select count(gid) from Tgongwen 

用时：1483毫秒

select count(fariqi) from Tgongwen

用时：3140毫秒

select count(title) from Tgongwen

用时：52050毫秒

从以上能够看出，若是用count(*)和用count(主键)的速度是至关的，而count(*)却比其余任何除主键之外的字段汇总速度要快，并且字段越长，汇总的速度就越慢。我想，若是用count(*)， SQL SERVER可能会自动查找最小字段来汇总的。固然，若是您直接写count(主键)将会来的更直接些。

十一、order by按汇集索引列排序效率最高

咱们来看：（gid是主键，fariqi是聚合索引列）

select top 10000 gid,fariqi,reader,title from tgongwen

用时：196 毫秒。 扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc

用时：4720毫秒。 扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用时：4736毫秒。 扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc

用时：173毫秒。 扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc

用时：156毫秒。 扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。

从以上咱们能够看出，不排序的速度以及逻辑读次数都是和“order by 汇集索引列” 的速度是至关的，但这些都比“order by 非汇集索引列”的查询速度是快得多的。

同时，按照某个字段进行排序的时候，不管是正序仍是倒序，速度是基本至关的。

十二、高效的TOP

事实上，在查询和提取超大容量的数据集时，影响数据库响应时间的最大因素不是数据查找，而是物理的I/0操做。如：

select top 10 * from (

select top 10000 gid,fariqi,title from tgongwen

where neibuyonghu='办公室'

order by gid desc) as a

order by gid asc

这条语句，从理论上讲，整条语句的执行时间应该比子句的执行时间长，但事实相反。由于，子句执行后返回的是10000条记录，而整条语句仅返回10条语句，因此影响数据库响应时间最大的因素是物理I/O操做。而限制物理I/O操做此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQL SERVER中通过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现TOP确实很好用，效率也很高。但这个词在另一个大型数据库ORACLE中却没有，这不能说不是一个遗憾，虽然在ORACLE中能够用其余方法（如：rownumber）来解决。在之后的关于“实现千万级数据的分页显示存储过程”的讨论中，咱们就将用到TOP这个关键词。

 

到此为止，咱们上面讨论了如何实现从大容量的数据库中快速地查询出您所须要的数据方法。固然，咱们介绍的这些方法都是“软”方法，在实践中，咱们还要考虑各类“硬”因素，如：网络性能、服务器的性能、操做系统的性能，甚至网卡、交换机等。

 

3、实现小数据量和海量数据的通用分页显示存储过程

创建一个web 应用，分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是:ADO 纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，由于游标自己有缺点：游标是存放在内存中，很费内存。游标一创建，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的手段，通常使用游标来逐行遍历数据，根据取出数据条件的不一样进行不一样的操做。而对于多表和大表中定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等待甚至死机。

更重要的是，对于很是大的数据模型而言，分页检索时，若是按照传统的每次都加载整个数据源的方法是很是浪费资源的。如今流行的分页方法通常是检索页面大小的块区的数据，而非检索全部的数据，而后单步执行当前行。

    最先较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯存储过程”。这个存储过程用了游标，因为游标的局限性，因此这个方法并无获得你们的广泛承认。

后来，网上有人改造了此存储过程，下面的存储过程就是结合咱们的办公自动化实例写的分页存储过程：

CREATE procedure pagination1

(@pagesize int,  --页面大小，如每页存储20条记录

@pageindex int   --当前页码

)

as

set nocount on

begin

declare @indextable table(id int identity(1,1),nid int)  --定义表变量

declare @PageLowerBound int  --定义此页的底码

declare @PageUpperBound int  --定义此页的顶码

set @PageLowerBound=(@pageindex-1)*@pagesize

set @PageUpperBound=@PageLowerBound+@pagesize

set rowcount @PageUpperBound

insert into @indextable(nid) select gid from TGongwen where fariqi >dateadd(day,-365,getdate()) order by fariqi desc

select O.gid,O.mid,O.title,O.fadanwei,O.fariqi from TGongwen O,@indextable t where O.gid=t.nid

and t.id>@PageLowerBound and t.id<=@PageUpperBound order by t.id

end

set nocount off

以上存储过程运用了SQL SERVER的最新技术――表变量。应该说这个存储过程也是一个很是优秀的分页存储过程。固然，在这个过程当中，您也能够把其中的表变量写成临时表：CREATE TABLE #Temp。但很明显，在SQL SERVER中，用临时表是没有用表变量快的。因此笔者刚开始使用这个存储过程时，感受很是的不错，速度也比原来的ADO的好。但后来，我又发现了比此方法更好的方法。

笔者曾在网上看到了一篇小短文《从数据表中取出第n条到第m条的记录的方法》，全文以下：

从publish 表中取出第 n 条到第 m 条的记录： 
SELECT TOP m-n+1 * 
FROM publish 
WHERE (id NOT IN 
　　　　(SELECT TOP n-1 id 
　　　　 FROM publish)) 

id 为publish 表的关键字 

我当时看到这篇文章的时候，真的是精神为之一振，以为思路很是得好。等到后来，我在做办公自动化系统（ASP.NET+ C#＋SQL SERVER）的时候，突然想起了这篇文章，我想若是把这个语句改造一下，这就多是一个很是好的分页存储过程。因而我就满网上找这篇文章，没想到，文章还没找到，却找到了一篇根据此语句写的一个分页存储过程，这个存储过程也是目前较为流行的一种分页存储过程，我很后悔没有争先把这段文字改形成存储过程：

CREATE PROCEDURE pagination2
(
 @SQL nVARCHAR(4000),    --不带排序语句的SQL语句
 @Page int,              --页码
 @RecsPerPage int,       --每页容纳的记录数
 @ID VARCHAR(255),       --须要排序的不重复的ID号
 @Sort VARCHAR(255)      --排序字段及规则
)
AS

DECLARE @Str nVARCHAR(4000)

SET @Str='SELECT   TOP '+CAST(@RecsPerPage AS VARCHAR(20))+' * FROM ('+@SQL+') T WHERE T.'+@ID+'NOT IN 
(SELECT   TOP '+CAST((@RecsPerPage*(@Page-1)) AS VARCHAR(20))+' '+@ID+' FROM ('+@SQL+') T9 ORDER BY '+@Sort+') ORDER BY '+@Sort

PRINT @Str

EXEC sp_ExecuteSql @Str
GO

其实，以上语句能够简化为：

SELECT TOP 页大小 *

FROM Table1

WHERE (ID NOT IN

          (SELECT TOP 页大小*页数 id

         FROM 表

         ORDER BY id))

ORDER BY ID

但这个存储过程有一个致命的缺点，就是它含有NOT IN字样。虽然我能够把它改造为：

SELECT TOP 页大小 *

FROM Table1

WHERE not exists

(select * from (select top (页大小*页数) * from table1 order by id) b where b.id=a.id )

order by id

即，用not exists来代替not in，但咱们前面已经谈过了，两者的执行效率其实是没有区别的。

既便如此，用TOP 结合NOT IN的这个方法仍是比用游标要来得快一些。

虽然用not exists并不能挽救上个存储过程的效率，但使用SQL SERVER中的TOP关键字倒是一个很是明智的选择。由于分页优化的最终目的就是避免产生过大的记录集，而咱们在前面也已经提到了TOP的优点，经过TOP 便可实现对数据量的控制。

在分页算法中，影响咱们查询速度的关键因素有两点：TOP和NOT IN。TOP能够提升咱们的查询速度，而NOT IN会减慢咱们的查询速度，因此要提升咱们整个分页算法的速度，就要完全改造NOT IN，同其余方法来替代它。

咱们知道，几乎任何字段，咱们均可以经过max(字段)或min(字段)来提取某个字段中的最大或最小值，因此若是这个字段不重复，那么就能够利用这些不重复的字段的max或min做为分水岭，使其成为分页算法中分开每页的参照物。在这里，咱们能够用操做符“>”或“<”号来完成这个使命，使查询语句符合SARG形式。如：

Select top 10 * from table1 where id>200

因而就有了以下分页方案：

select top 页大小 *

from table1 

where id>

      (select max (id) from 

      (select top ((页码-1)*页大小) id from table1 order by id) as T

       )     

  order by id

在选择即不重复值，又容易分辨大小的列时，咱们一般会选择主键。下表列出了笔者用有着1000万数据的办公自动化系统中的表，在以GID（GID是主键，但并非汇集索引。）为排序列、提取gid,fariqi,title字段，分别以第一、十、100、500、1000、1万、10万、25万、50万页为例，测试以上三种分页方案的执行速度：（单位：毫秒）

页  码
 方案1
 方案2
 方案3
 
1
 60
 30
 76
 
10
 46
 16
 63
 
100
 1076
 720
 130
 
500
 540
 12943
 83
 
1000
 17110
 470
 250
 
1万
 24796
 4500
 140
 
10万
 38326
 42283
 1553
 
25万
 28140
 128720
 2330
 
50万
 121686
 127846
 7168
 

从上表中，咱们能够看出，三种存储过程在执行100页如下的分页命令时，都是能够信任的，速度都很好。但第一种方案在执行分页1000页以上后，速度就降了下来。第二种方案大约是在执行分页1万页以上后速度开始降了下来。而第三种方案却始终没有大的降势，后劲仍然很足。

在肯定了第三种分页方案后，咱们能够据此写一个存储过程。你们知道SQL SERVER的存储过程是事先编译好的SQL语句，它的执行效率要比经过WEB页面传来的SQL语句的执行效率要高。下面的存储过程不只含有分页方案，还会根据页面传来的参数来肯定是否进行数据总数统计。

-- 获取指定页的数据

CREATE PROCEDURE pagination3

@tblName   varchar(255),       -- 表名

@strGetFields varchar(1000) = '*',  -- 须要返回的列 

@fldName varchar(255)='',      -- 排序的字段名

@PageSize   int = 10,          -- 页尺寸

@PageIndex  int = 1,           -- 页码

@doCount  bit = 0,   -- 返回记录总数, 非 0 值则返回

@OrderType bit = 0,  -- 设置排序类型, 非 0 值则降序

@strWhere  varchar(1500) = ''  -- 查询条件 (注意: 不要加 where)

AS

declare @strSQL   varchar(5000)       -- 主语句

declare @strTmp   varchar(110)        -- 临时变量

declare @strOrder varchar(400)        -- 排序类型

 

if @doCount != 0

  begin

    if @strWhere !=''

    set @strSQL = "select count(*) as Total from [" + @tblName + "] where "+@strWhere

    else

    set @strSQL = "select count(*) as Total from [" + @tblName + "]"

end  

--以上代码的意思是若是@doCount传递过来的不是0，就执行总数统计。如下的全部代码都是@doCount为0的状况

else

begin

 

if @OrderType != 0

begin

    set @strTmp = "<(select min"

set @strOrder = " order by [" + @fldName +"] desc"

--若是@OrderType不是0，就执行降序，这句很重要！

end

else

begin

    set @strTmp = ">(select max"

    set @strOrder = " order by [" + @fldName +"] asc"

end

 

if @PageIndex = 1

begin

    if @strWhere != ''   

    set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ "  from [" + @tblName + "] where " + @strWhere + " " + @strOrder

     else

     set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ "  from ["+ @tblName + "] "+ @strOrder

--若是是第一页就执行以上代码，这样会加快执行速度

end

else

begin

--如下代码赋予了@strSQL以真正执行的SQL代码

set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ "  from ["

    + @tblName + "] where [" + @fldName + "]" + @strTmp + "(["+ @fldName + "]) from (select top " + str((@PageIndex-1)*@PageSize) + " ["+ @fldName + "] from [" + @tblName + "]" + @strOrder + ") as tblTmp)"+ @strOrder

 

if @strWhere != ''

    set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ "  from ["

        + @tblName + "] where [" + @fldName + "]" + @strTmp + "(["

        + @fldName + "]) from (select top " + str((@PageIndex-1)*@PageSize) + " ["

        + @fldName + "] from [" + @tblName + "] where " + @strWhere + " "

        + @strOrder + ") as tblTmp) and " + @strWhere + " " + @strOrder

end 

end   

exec (@strSQL)

GO

上面的这个存储过程是一个通用的存储过程，其注释已写在其中了。

在大数据量的状况下，特别是在查询最后几页的时候，查询时间通常不会超过9秒；而用其余存储过程，在实践中就会致使超时，因此这个存储过程很是适用于大容量数据库的查询。

笔者但愿可以经过对以上存储过程的解析，能给你们带来必定的启示，并给工做带来必定的效率提高，同时但愿同行提出更优秀的实时数据分页算法。

 

4、汇集索引的重要性和如何选择汇集索引

在上一节的标题中，笔者写的是：实现小数据量和海量数据的通用分页显示存储过程。这是由于在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程在小数据量的状况下，有以下现象：

一、分页速度通常维持在1秒和3秒之间。

二、在查询最后一页时，速度通常为5秒至8秒，哪怕分页总数只有3页或30万页。

虽然在超大容量状况下，这个分页的实现过程是很快的，但在分前几页时，这个1－3秒的速度比起第一种甚至没有通过优化的分页方法速度还要慢，借用户的话说就是“尚未ACCESS数据库速度快”，这个认识足以致使用户放弃使用您开发的系统。

笔者就此分析了一下，原来产生这种现象的症结是如此的简单，但又如此的重要：排序的字段不是汇集索引！

本篇文章的题目是：“查询优化及分页算法方案”。笔者只因此把“查询优化”和“分页算法”这两个联系不是很大的论题放在一块儿，就是由于两者都须要一个很是重要的东西――汇集索引。

在前面的讨论中咱们已经提到了，汇集索引有两个最大的优点：

一、以最快的速度缩小查询范围。

二、以最快的速度进行字段排序。

第1条多用在查询优化时，而第2条多用在进行分页时的数据排序。

而汇集索引在每一个表内又只能创建一个，这使得汇集索引显得更加的重要。汇集索引的挑选能够说是实现“查询优化”和“高效分页”的最关键因素。

但要既使汇集索引列既符合查询列的须要，又符合排序列的须要，这一般是一个矛盾。

笔者前面“索引”的讨论中，将fariqi，即用户发文日期做为了汇集索引的起始列，日期的精确度为“日”。这种做法的优势，前面已经提到了，在进行划时间段的快速查询中，比用ID主键列有很大的优点。

但在分页时，因为这个汇集索引列存在着重复记录，因此没法使用max或min来最为分页的参照物，进而没法实现更为高效的排序。而若是将ID主键列做为汇集索引，那么汇集索引除了用以排序以外，没有任何用处，其实是浪费了汇集索引这个宝贵的资源。

为解决这个矛盾，笔者后来又添加了一个日期列，其默认值为getdate()。用户在写入记录时，这个列自动写入当时的时间，时间精确到毫秒。即便这样，为了不可能性很小的重合，还要在此列上建立UNIQUE约束。将此日期列做为汇集索引列。

有了这个时间型汇集索引列以后，用户就既能够用这个列查找用户在插入数据时的某个时间段的查询，又能够做为惟一列来实现max或min，成为分页算法的参照物。

通过这样的优化，笔者发现，不管是大数据量的状况下仍是小数据量的状况下，分页速度通常都是几十毫秒，甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝。

汇集索引是如此的重要和珍贵，因此笔者总结了一下，必定要将汇集索引创建在：

一、您最频繁使用的、用以缩小查询范围的字段上；

二、您最频繁使用的、须要排序的字段上。