随着系统数据的增多，一些查询逐渐变慢，这时候我们可以根据sqlserver的执行计划，查看sql的开销，然后根据开销创建索引。

索引有聚集索引与非聚集索引。

聚集索引：聚集索引在存储上是按照顺序存储的，就像字典里的汉字。

非聚集索引：物理存储不连续，但逻辑上是连续的，因为单独维护着数据的存储位置与数据的关系。

首先写入100000数据

DECLARE @i INT,
@num int
SET @i=0
SET @num=100000
WHILE @i<=@num
BEGIN    IF NOT EXISTS(SELECT * FROM  dbo.meter_manage WHERE meter_id=@i)    INSERT INTO dbo.meter_manage    ( meter_id ,    meter_no ,    meter_name     )    VALUES    ( @i , -- meter_id - int    'asdasd'+CONVERT(VARCHAR(20),@i), -- meter_no - varchar(500)    'asdsf'++CONVERT(VARCHAR(20),@i)  -- meter_name - varchar(500)
         );    SET @i=@i+1;
END    go

非聚集索引的创建：

create NONCLUSTERED INDEX index1 ON meter_manage(meter_no)  

效果：

select * from meter_manage where meter_no='asdasd2'

创建非聚集索引之前，耗时23毫秒左右

创建非聚集索引之后，瞬间完成

经常使用多条件语句查询时，我们可创建复合索引。

select * from meter_manage where meter_no='asdasd2' and meter_name='asdsf2'

未创建非聚集索引，耗时30毫秒：

在meter_no字段创建单索引，耗时3毫秒：

create NONCLUSTERED INDEX index1 ON meter_manage(meter_no)  

条件查询位置更换：

select * from meter_manage where meter_name='asdsf2' and  meter_no='asdasd2' 

查询速度没变，同样3毫秒。

我们同时在另一个字段meter_name上也建立一个非聚集索引：

create NONCLUSTERED INDEX index2 ON meter_manage(meter_name)  

发现两个非聚集索引的时间与一个聚集索引的时间没有太大变化，查看执行计划，只命中了index1索引：

分析：

我们来想象一下当数据库有N个索引并且查询中分别都要用上他们的情况：
查询优化器（用大白话说就是生成执行计划的那个东西）需要进行N次主二叉树查找[这里主二叉树的意思是最外层的索引节点]，此处的查找流程大概如下：
查出第一条column1主二叉树等于1的值，然后去第二条column2主二叉树查出foo的值并且当前行的coumn1必须等于1，最后去column主二叉树查找bar的值并且column1必须等于1和column2必须等于foo。
如果这样的流程被查询优化器执行一遍，就算不死也半条命了，查询优化器可等不及把以上计划都执行一遍，贪婪算法（最近邻居算法）可不允许这种情况的发生，所以当遇到以下语句的时候，数据库只要用到第一个筛选列的索引（column1），就会直接去进行表扫描了。

select count(1) from table1 where column1 = 1 and column2 = 'foo' and column3 = 'bar'

所以与其说是数据库只支持一条查询语句只使用一个索引，倒不如说N条独立索引同时在一条语句使用的消耗比只使用一个索引还要慢。
所以如上条的情况，最佳推荐是使用index(column1,column2,column3） 这种联合索引，此联合索引可以把b+tree结构的优势发挥得淋漓尽致：
一条主二叉树（column=1），查询到column=1节点后基于当前节点进行二级二叉树column2=foo的查询，在二级二叉树查询到column2=foo后，去三级二叉树column3=bar查找。

结论：两个单独索引通常数据库只能使用其中一个

创建复合索引：

create index idx1 on meter_manage(meter_no,meter_name) 

瞬间完成，发现多条件下适合创建复合索引。

条件位置改变一下

select * from meter_manage where meter_name='asdsf2' and  meter_no='asdasd2' 

同样瞬间完成。查看执行计划命中了idx1

我们去掉二个条件：

select * from meter_manage where meter_no='asdasd2'

同样瞬间完成，也命中了索引  idx1

我们去掉第一个条件：

select * from meter_manage where meter_name='asdsf2'

耗时27毫秒，与不加索引没什么区别，查看执行计划，发现虽然命中了idx1

但是类型却是Index Scan，与之前的Index Seek不同

区别：

[Table Scan] 表扫描（最慢），对表记录逐行进行检查

[Clustered Index Scan] 聚集索引扫描（较慢），按聚集索引对记录逐行进行检查

[Index Scan] 索引扫描（普通），根据索引滤出部分数据在进行逐行检查

[Index Seek] 索引查找（较快），根据索引定位记录所在位置再取出记录

[Clustered Index Seek] 聚集索引查找（最快），直接根据聚集索引获取记录

因此，字段上同时存在聚集索引与非聚集索引，这种情况下只会命中聚集索引，因为聚集索引最快，例如：主键上创建非聚集索引

create NONCLUSTERED INDEX index3 ON meter_manage(meter_id)  

瞬间完成，执行计划：