背景:
索引分类：众所周知,索引分为聚集索引和非聚集索引。
索引优点：加速数据查询。
问题：然而我们真的清楚索引的应用吗?你写的查询语句是否能充分应用上索引,或者说你如何设计你的索引让它更高效？
经历:以前本人只知道索引的好处,但是是否能够真正让它发挥作用,并无太多理论,为些本人做了些DEMO,来简单说明下什么情况下才能充分利用索引。案例:
这里建立一个学生表:有如下字段,此时表中没有建立任何索引。
CREATE TABLE [dbo].[student]([ID] [int] IDENTITY(1,1) NOT NULL,--学生ID
[sUserName] [nchar](10) COLLATE Chinese_PRC_CI_AS NULL,--学生姓名
[sAddress] [varchar](200) COLLATE Chinese_PRC_CI_AS NULL,--学生地址
[classID] [int] NULL,--学生所属班级ID
[create_date] [datetime] NULL CONSTRAINT [DF_student_create_date] DEFAULT (getdate()) --入校时间
) ON [PRIMARY]
业务需求:
查询班级ID为9的所有学生的姓名和地址。
情况一:--字段没有建立任何索引
select sUserName,sAddress from student
where classID=9
执行计划如下图：
情况二:
给ID自增列创建一个聚集索引,我们很多情况下都是这样默认的,主键上就是聚集索引。同样的查询,不同的查询计划,发现此时虽然在输出列和条件中没有ID,但是查询选择了聚集查询.
执行计划图同图一。
结论:虽然条件列中出现了classID索引列,但是输出列中并没有创建任何索引,依然选用聚集扫描方式查询.
结论:同上
情况五:继续在sAddress上创建非聚集索引 结论:同上
结论:同上
结论:同上
情况八:在classID,sUserName,sAddress上创建联合非聚集索引
执行计划图如下：
结论:当条件中出现的列加上输出列和联合索引列完全匹配时全用上索引扫描.
情况九：删除所有索引，保留ID的聚集索引。以聚集索引列做为条件之一来查询.
select sUserName,sAddress from student
where ID=10021002
或者：select sUserName,sAddress from student
where ID=10021002 and classID=9
执行计划图：
所有情况总结:
1:当使用非聚集索引扫描时的IO情况:表 'student'。扫描计数 1，逻辑读取 70 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
2:当使用聚集索引扫描时的IO情况(条件中未出现聚集索引列):表 'student'。扫描计数 3，逻辑读取 8835 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
3:当使用聚集索引扫描时的IO情况（条件中出现聚集索引列） :表 'student'。扫描计数 1，逻辑读取 3 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
结论:
1:在没有正确的索引情况下,会增加表的扫描次数.
2:数据在查询时会先找匹配的索引.1):如果在条件列中出现聚集索引列,则无论输出列是否建立索引都会按聚集索引查找(有聚集索引 ).
2):如果在条件列中没有出现聚集索引列,则查找匹配的非聚集索引,如果有匹配的索引则按相应索引查询,否则再扫描聚集索引(有聚集索引 ).
3):查找匹配的非聚集索引(没有聚集索引 ).
本文总结：
我只是简单的写了些关于索引使用的DEMO，在实际开发中要按实际情况来分析，有时并不能完全使用上索引，但是可以让查询产生最少的IO读取以及表扫描次数。