SQL索引之聚簇索引

       创建聚簇索引：CREATE CLUSTERED INDEX [索引名] ON 表名 (列名)。

       由聚簇索引的定义可以得知，其拷贝表是按照建立聚簇索引的字段来进行排序的，因此建立聚簇索引的最大好处是当我们经常用建立聚簇索引的字段来作为条件进行查询的时候可以很快查找出我们想要的记录避免全表扫描。默认情况下一个数据表的聚簇索引是其主键。下面的数据表经常指的是大数据表。

       当我们经常使用主键Id作为查询条件的时候，我们可以不用更改其聚簇索引。而当我们的数据表经常被查询，但是查询条件不是主键Id的时候，我们就需要考虑另外创建聚簇索引或者建立非聚簇索引（何时选择哪个再做讨论）。

       一些零碎的归纳：

          测试数据库：SQL Server 2008   数据量：90W

      1. select * from TestTable2 where id > 300 and Id<500
          select * from TestTable2 where Id<500 and Id>300。在Id建立主键的情况下，第一条语句的效率应该比第二条语句的效率低，因为第二条语句能更快的缩小查询范围。但是经过测试后发现他们的逻辑访问次数，I/O时间开始时差不多的。因为查询分析器会帮我们在查询之前进行优化。网上都说第一条语句效率比较低。实践是检验真理的唯一标准。

       2. select * from TestTable2 where id < 300

           select * from TestTable2 where id <=299   发现这两个执行效率也是差不多。

       3.select * from TestTable2 where Id=1001 or Id=22 or Id=4554
          select * from TestTable2 where Id  in(1001,22,4554)  发现在Id是集簇索引或者是非集簇索引下，都能得到索引优化。而且两者效率差不多。

       4.select * from TestTable2 where Id=SQRT(100) 发现在集簇索引和非集簇索引下这样都可以利用到索引的优化。因为函数应用是自匹配的值。

          select * from dbo.testtable2 where UPPER(Name)='WUXIAOQIAN999' 这样不能进行优化，因为函数应用的是匹配数据库的列。

        接下来对.NET成员角色管理器的数据库做索引分析。分析的数据表是，aspnet_Membership和aspnet_Users。在aspnet_Users表中，集簇索引是ApplicationId和LoweredUserName的组合。在应用程序中，我们经常会根据UserName(用户名)作为条件来查询UserId或者密码等等，因此对UserName建立索引是合理的，但是这里并没有用UserName而是LoweredUserName。分析的重点是在用LoweredUserName而不用UserName，至于ApplicationId不是主要分析对象。由于用户在登录时，登录用户名是不区分大小写的，但是用户在注册时填入的大小写是有区分意义的。因此在注册存入数据库时，要和用户输入的用户名保持一致，而不能将其统一大写或者统一小写存入。但是用户登录是有时不区分大小写的。这样我们在查询匹配时统一大小写处理如：SELECT  @NewUserId = UserId FROM dbo.aspnet_Users WHERE LOWER(@UserName) =LOWER(@UserName) AND @ApplicationId = ApplicationId。这样就不能利用索引了。除非强制用户登录时，大小写是区分的。因此在数据表中，多了一个LoweredUserName列用来存储用户名的小写。这样在数据库查询时是这样的：SELECT  @NewUserId = UserId FROM dbo.aspnet_Users WHERE LOWER(@UserName) = LoweredUserName AND @ApplicationId = ApplicationId。这样就能充分利用到索引了。在aspnet_Membership中也是如此的。