SQL Server索引设计 <第五篇>

SQL Server索引的设计主要考虑因素以下：

　　检查WHERE条件和链接条件列；

　　使用窄索引；

　　检查列的选择性；

　　检查列的数据类型；

　　考虑列顺序；

　　考虑索引类型(汇集索引OR非汇集索引)；

1、检查WHERE条件列和连接条件列                                                                             

　　当一个查询提交到SQL Server时，查询优化器尝试为查询中引用的全部表查找最佳的数据访问机制。下面列出查询优化器针对WHERE和链接的工做方式：

1. 优化器识别WHERE子句和链接条件中包含的列。
2. 接着优化器检查这些列上的索引。
3. 优化器经过从索引上维护的统计肯定子句的选择性，评估每一个索引的有效性。
4. 最终，优化器根据前面几个步骤中手机的信息，估计读取所限定行开销最低的方法。

　　为了理解WHERE子句在查询中的重要性，来考虑一个示例。

　　SELECT * FROM Person WHERE Id = 100;

　　假设上面的表Id列为汇集索引。上面的语句有了WHERE子句，查询优化器将检查WHERE子句的列Id，肯定Id列上有汇集索引，从汇集索引上的统计评估WHERE子句的高选择性，而且决定使用这个索引。

　　查询优化器的表现说明，WHERE子句列帮助优化器选择一个对查询最优的索引操做。这也适用于两个表之间的链接条件中使用的列。优化器查找到WHERE子句或链接条件列上的索引，若是可用，考虑使用该索引来从表中检索行。查询优化器在执行一个查询时，考虑WHERE子句或链接条件列上的索引。所以WHERE子句或链接条件中频繁使用的列上有索引将帮助优化器避免基本表的扫描。

　　可是，当一个表中的数据总量很是小以致于能够放入一个数据页，那么表扫描可能比索引查找更快，若是有一个好的索引，可是仍然进行扫描，能够考虑这个问题。

2、使用窄索引                                                                                                             

　　能够在表中的一个列组合上建立索引，可是为了最好的性能，尽可能在索引中使用较少的列。还应该避免在索引中使用宽数据类型的列。

• 　　窄索引：索引中的列数尽量少；
• 　　宽数据类型：占用空间比较大的数据类型，如：CHAR、VARCHAR、NVARCHAR、CLOB等。除非绝对必须，不然在索引中要把大尺寸的宽数据类型的列的使用降到最少。

　　窄索引能够在8KB的索引页面上容纳比宽索引更多的行，这将有以下优势：

1. 减小I/O数量(读取更少的8KB页面)；
2. 使数据库缓存更有效，由于SQL Server能够缓存更少的索引页面，从而减小内存中的索引页面所需的逻辑读操做；
3. 减小数据库存储空间；

 　　下面之后一个示例来讲明窄索引的好处：

　　第一次，咱们的索引仅仅包含Name列：

 　　

　　第二次，咱们的索引INCLUDE多了两列：

　　

　　咱们看到。包含多了两个列以后，逻辑读取比一个列多？为何呢？由于包含多了两个列，索引须要占用更大的空间，一个数据页放的索引行少了，就须要读取更多的数据页。

3、索引列的选择性                                                                                                      

　　索引，特别是非汇集索引，主要在索引中有至关高级别的选择性的状况下是有益的。所谓选择性，指的是列中惟一值的百分比。列中的惟一值百分比越高，选择性就越高，从而索引的溢出就越大。若是一个表中有2000条记录，表索引列有1990个不一样的值，那么这个索引的选择性就是1980/2000=0.99。

　　在前面的学习中已经了解到，在非汇集索引中的查询实际上只是开始。要找到真正的数据，仍须要对汇集索引再执行一次循环遍历。甚至使用堆上的非汇集索引，仍然须要执行多个单独的物理读操做。

　　若是在非汇集索引中的一个查找将要在汇集索引上产生多个额外的查找，那么进行表扫描可能更好。这里可能产生的影响其实是很是惊人的。若是被索引的列惟一性达不到90%~95%，那么考虑由非汇集索引建立的循环过程是不值得的。好比一个性别选项，设置为了bit，而后建索引。查询优化器是不会考虑使用这种索引的。

　　由以上的分析，可知主键的选择性是100%，选择性越接近主键，建在该列的索引的效率就会越高。

　　索引的可选择性是衡量索引的利用率的方法，好比在极端的状况下，一个表记录数是1000，而索引列的值只有5个不一样的值，则索引的可选择性不好（只有0.005）。这样的情形使用全表扫描要比采用索引还好。

　　下面来实操下，计算下索引的选择性，固然测试表数据小，可能查询时即便有了索引，SQLServer也未必会用。

　　

　　由以上信息可计算获得对fdkeyname列的索引选择性为

　　110/119 = 0.924

　　这样仍是麻烦啊？难道手工算吗？下面给出一条SQL语句查出选择性的方法：

SELECT CAST(count(DISTINCT fdkeyname) AS FLOAT) / CAST(count(*) AS FLOAT)
FROM JM_Keyword;

　　

　　选择性规则的一个例外与外键有关，若是表中有一列是外键，那么在该列上有一个索引，这极可能是有益的。为何是外键而不是其余列呢？外键经常是与它们引用的表链接的目标。无论选择性如何，索引在链接性能方面是很是有帮助的，由于它们容许合并链接。合并链接从每一个表中获取一行进行比较，查看它们是否和链接条件匹配。由于两个表中的相关列上都存在索引，因此对两个行的查找是很是快的。

　　下面以一个示例来讲明问题：

　　我在一个Person表中的性别列创建了一个索引，而后来查看查询优化器的查询方式：

　　

　　为何查询优化器不选择从Gender列的索引来查找数据呢?

　　我要返回前10条性别为"男"数据，若是使用索引，咱们知道这个Gender列上的索引的选择性大约为50%。SQL Server即便经过索引找到了前10条性别为男的汇集列，也还要再经过Id到汇集索引中去查找数据，这样还不如直接扫描汇集表快。所以SQL Server的查询优化器忽略了这个索引。

　　经过WITH INDEX(索引名)能够强制使用索引查找，下面给出这两种查询方式的读取次数比较：

　　强制索引方式读取：

　　

　　查询优化器选择读取：

　　

　　由上面咱们能够看到，强制使用索引的话，逻辑读取高，可是预读少。咱们知道预读是与分析并行执行，并且可以载入缓存中的。从SQL Server的选择来看，基本上能够得出一个结论，逻辑读比预读更加占用时间。

4、检查索引的数据类型                                                                                              

　　索引列的数据类型也是很重要的。例如，在一个整数键值上的索引查询是很是快的，这是由于int数据类型的尺寸很小，并且算数操纵很容易。也可使用int数据的其余变种(bigint,smallint,tinyint)做为索引列，而字符串数据类型(char、varchar、nchar、ncarchar、)须要字符串匹配操做，这一般比整数匹配操做的开销更大。

 　　假设但愿在一列上建立索引但却有两个候选列，一个是int数据类型，一个是char(4)数据类型。这两种数据类型在SQL Server 2008中大小都是4字节，可是仍然应该首选int数据类型做为索引。由于char(4)数据类型中的值1实际上保存为1后面跟着3个空格，4个字节组合是0x3五、0x20、0x20、0x20。CPU不理解如何在这个数据上执行算数运算。所以在算数操做以前要将其转换为一个整数，而在int数据类型中，值1被保存为0x00000001。CPU能够简单地在这个数据上执行算数运算。

5、索引列顺序                                                                                                           

　　索引键值在索引的第一列上排序，而后再一次再下一列中排序。

　　假设咱们的在一张表中创建一个复合索引：

　　CREATE NONCLUSTERED INDEX indexName ON Table(c1,c2) 

　　那么索引中的数据大概以下：

c1	c2
1	1
1	2
2	1
2	2
3	1
3	2

 　　假设大部分在上表上的查询与下面的语句相似

　　SELECT * FROM Table WHERE c1 = 1 或 2 　　SELECT * FROM Table WHERE c2 = 1 或 2 AND c1 = 1 或 2

　　(c2,c1)对上面两个查询都有利，可是(c1,c2)上的索引就不合适，由于它首先在c1上排序，而第一个SQL语句须要在c2上排序。

　　这就比如使用电话本。全部项都是按先姓后名的方式进行索引-若是值知道要通电话的人的名是“备”，那么这种排列顺序不能带来什么好处。另外一方面，若是只知道他的姓是“刘”，那么索引将能够用来缩小查找范围。

6、考虑索引类型                                                                                                         

　　考虑索引的类型 SQL Server中有两种主要的索引类型：汇集索引和非汇集索引。这两种类型都为B-树结构。二者之间的主要区别是汇集索引中的叶子页是表的数据。所以表中的数据和汇集索引的顺序相同，这意味着，汇集索引就是该表。在决定使用索引类型时，两种索引类型的叶子级别上的差异变得很是重要。

　　一个表只有一个汇集索引，应该明智地选择它。

　　SQLServer在默认状况下，主键和汇集索引是一块儿建立的。若是不想将主键声明为汇集索引，那么在建立表时，只需添加NONCLUSTERED关键字。

CREATE TABLE MyTableKeyExample { 　　Column1 int IDENTITY 　　　　PRIMARY KEY NONCLUSTERED, 　　Column2 int }

　　一旦建立了索引，改变它的惟一方法是删除和重建它，因此须要一开始就作对。

　　若是改变了汇集索引所在的列，那么SQL Server将须要对整个表彻底从新排序(由于对于汇集索引，表的排列顺序和索引顺序是相同的)。

　　对于数据比较多的表，改变汇集索引，须要从新排序的数据很是多，要从如下几个方面进行考虑。

　　它将须要花费多长时间。 　　是否有足够的空间？为了在汇集索引上执行从新排序，额外须要的平均空间量将为表已经占用空间量的1.2倍。确保有足够的空间来操做。 　　应当使用SORT_IN_TEMPDB选项吗？若是tempdb位于与主数据库不一样的物理阵列上，而且它有足够的空间，那么答案是确定的。

　　一、正面观点

　　若是列常做为范围查询的对象，那么汇集索引对这类查询是颇有用的。这类查询一般使用between语句或<or>符号。使用GROUP BY以及利用MAX、MIN和COUNT聚合函数的查询也是使用范围和偏好汇集索引的查询的重要示例。汇集索引适合用于此处，是由于搜索能够直接到达物理数据中的特定点，可一直读数据，直到范围的末端，而后中止。这种方法很是有效。当想要数据基于汇集键排序(ORDER BY),汇集也是极好的方法。

　　二、反面观点

　　有两种状况下，你可能不想建立汇集索引。

　　(1)、当有更好的位置来使用它时。不要由于列看上去适合作汇集索引就将它用做汇集索引(主键是最多见的罪魁祸首)-要肯定没有更合适的其余列。

　　(2)、在将要以非连续的顺序进行大量插入时。这会进行页拆分，而且会消耗大量时间。

　　例如，一个交易系统，用

　　ARXXXX

　　GLXXXX

　　APXXXX

　　做为主键，并使用默认的汇集索引，那么在插入数据的时候，常常会发生页拆分。由于数据会按照汇集索引进行排序，那么不停的录入数据，就可能会常常性地发生页拆分，引发短暂停顿。

　　幸运的是，有一些方法能够避免以上情形：

　　选择在插入时是连续的汇集键。能够以此建立一个标识列，或者也可使用另外一个列，该列对于任何输入交易来讲，在逻辑上都是连续的。

　　选择不在这个表上使用汇集索引。对于相似的这里的情形来讲，这一般是最好的选择，由于在对上非汇集索引中的插入通常比在汇集键上的插入更快。　　

　　什么时候应该使用汇集索引与非汇集索引

动做描述 　　　　　　 使用汇集索引 　　　　 使用非汇集索引

列常常被分组排序 　　 应 　　　　　　　　　 应

返回某范围内的数据 　 应 　　　　　　　　　 不该

一个或极少不一样值 　　 不该 　　　　　　　　 不该

小数目的不一样值 　　　 应 　　　　　　　　　 不该

大数目的不一样值 　　    不该 　　　　　　　　 应

频繁更新的列 　　　　 不该 　　　　　　　　 应

外键列 　　　　　　　 应 　　　　　　　　　 应

主键列 　　　　　　　 应 　　　　　　　　　 应

频繁修改索引列 　　　 不该 　　　　　　　　 应

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

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

下面列出在实践中的一些误区:

一、主键就是索引

　　这种想法是极端错误的，是对汇集索引的一种浪费。虽然SQL SERVER默认是在竹简上简历汇集索引的。一般，咱们会在每一个表都创建一个Id列，以区分每条数据，而且这个Id列是自动增大的，增加量一半设为1。以一个办公自动化的紫铜为例子。若是将Id列设为主键，SQL SERVER会将此列默认为汇集索引，这样作有好处，就是可让你的数据在数据库中按照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个不一样记录。在此字段上创建聚合索引是再合适不过了。在现实中，咱们天天都会发几个文件，这几个文件的发文日期就相同，这彻底符合创建汇集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，咱们创建“适当”的聚合索引对于咱们提升查询速度是很是重要的。 事实上，咱们能够发现上面的例子中，第二、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毫秒 

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

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

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

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

　　在上一节的标题中，笔者写的是：实现小数据量和海量数据的通用分页显示存储过程。这是由于在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程在小数据量的状况下，有以下现象： 
一、分页速度通常维持在1秒和3秒之间。 
二、在查询最后一页时，速度通常为5秒至8秒，哪怕分页总数只有3页或30万页。 

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

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

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

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

     二、以最快的速度进行字段排序。 
第1条多用在查询优化时，而第2条多用在进行分页时的数据排序。 
　　而汇集索引在每一个表内又只能创建一个，这使得汇集索引显得更加的重要。汇集索引的挑选能够说是实现“查询优化”和“高效分页”的最关键因素。  　　

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

      笔者前面“索引”的讨论中，将fariqi，即用户发文日期做为了汇集索引的起始列，日期的精确度为“日”。这种做法的优势，前面已经提到了，在进行划时间段的快速查询中，比用ID主键列有很大的优点。 
     但在分页时，因为这个汇集索引列存在着重复记录，因此没法使用max或min来最为分页的参照物，进而没法实现更为高效的排序。而若是将ID主键列做为汇集索引，那么汇集索引除了用以排序以外，没有任何用处，其实是浪费了汇集索引这个宝贵的资源。

　　为解决这个矛盾，笔者后来又添加了一个日期列，其默认值为getdate()。用户在写入记录时，这个列自动写入当时的时间，时间精确到毫秒。即便这样，为了不可能性很小的重合，还要在此列上建立UNIQUE约束。将此日期列做为汇集索引列。 
　　有了这个时间型汇集索引列以后，用户就既能够用这个列查找用户在插入数据时的某个时间段的查询，又能够做为惟一列来实现max或min，成为分页算法的参照物。  　　

通过这样的优化，笔者发现，不管是大数据量的状况下仍是小数据量的状况下，分页速度通常都是几十毫秒，甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝。  汇集索引是如此的重要和珍贵，因此笔者总结了一下，必定要将汇集索引创建在：  　　

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

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