三：索引的建立原则
一般来说，建立索引要看数据使用的场景，换句话来说哪些访问数据的SQL语句是常用的，而这些语句是否因为缺少索引（也有可能是索引过多）变的效率低下。但绝不是所有的SQL语句都要建立索引，如果所有的SQL语句都建立索引，那么可能导致建立过多的索引。
我碰到过每秒钟新增记录超过千条的案例，虽然该数据表仅有聚集索引，但因为已存在的键值字段的值和新增数据键值字段的值并不是按顺序递增，每次新增记录时，肯定造成整体数据行的重新排列。在移掉聚集索引后，性能约提升20%。也曾经碰到过一个数据表上有20个索引，结果新增一条记录需要耗时4秒钟才能完成。
另一个案例中，POS系统中的销售数据变更，要同时更新多个数据表，每个数据表都有数十万条记录以上，但所使用的WHERE字段没有有效的索引，除查找缓慢外，导致更新时产生了大量的锁定。各数据表加上应有的索引后，原来要几十秒的更新，不到一秒钟便完成了。
另外，根据数据库的使用时机，也有可能先建立索引，用完后再删除。例如，当你做年报表、季报表时需要大量查询各种数据，可以考虑在生成报表之前建立相关索引。但在报表生成完毕后，为了保证平时新增、修改和删除操作的运行效率，再删除为了生成报表所建立的相关的索引。
而针对SQL语句或视图是否值得建立索引的问题，则有以下几个可以参考的方面。
第一、选择性
选择性表示符合你查询条件的记录占总记录的百分比，也就是
选择性=符合查询条件的记录数量/总记录数量
这个值越小越好，越小代表选择越高，越适合采用索引。例如 ：
select * from WBK_Goods_Info where COP_G_NO='00078027'
在WBK_Goods_Info 表内符合这个条件的记录只有1条，而整个数据表有100000条记录，因此该查询的选择性是1/100000，这代表非常高的选择性，如此通过索引来查找数据才有效率。反过来说，或你的语句如下：
Select * from WBK_Goods_Info with(index(idx_cop_g_no)) where COP_G_NO>'00018000'
这时符合查询记录达82000条，选择性变为82000/100000，说明选择性非常低，除非以COP_G_NO字段为键值建立的索引是聚集索引，否则如果采用非聚集索引来访问，反而变成需要读取至少82000次数据页，因为SQL SERVER在读取每一条记录时，都是先将整个数据页读取（请记住，这是SQL SERVER读取数据的基本单位），再从中取出目标记录。就算两条记录存在同一数据页上，也要读该数据页两次。因此在选择性很低时，通过非聚集索引访问是非常没有效率的访问方式，还不如直接进行全表扫描。
第二、数据密度
数据密度是指键值惟一的记录条数分之一，也就是
数据密度=1/键值惟一的记录数量
通过以下语句进行测试：在WBK_PDE_LIST_ORG_HISTROY数据表的COP_G_NO字段建立索引，而后通过dbcc show_statistics语句查询存储系统内关于该索引的统计信息的记录，而后再应用上方的公式，以测试是否与存储在系统内的ALL Density字段值是否相同：
--创建索引
CREATE NONCLUSTERED INDEX [idx_WBK_PDE_LIST_COP_G_NO] ON [dbo].[WBK_PDE_LIST_ORG_HISTROY]
(
[COP_G_NO] ASC
)
INCLUDE ( [WBOOK_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT])
--返回all desity字段的值
DBCC SHOW_STATISTICS ('WBK_PDE_LIST_ORG_HISTROY','idx_WBK_PDE_LIST_COP_G_NO')
--计算all desity字段的值
Select 1.0/(select count(distinct COP_G_NO) from WBK_PDE_LIST_ORG_HISTROY) [All Density]
当数据密度越小，也就是惟一性越高时，代表该字段越适合建立索引，因为当总数据条数乘上该密度值，就是一般平均查询到的记录数字。
第三、数据分布
数据分布代表多条数据记录组成的方式，与密度的概念有关。它代表数据记录是平均散布在一段范围内，还是集中在部分区块。其分布示意图如下图。
以我们的范例而言，每一种货物的货物编号都是自增且惟一的，也就是货物信息表(wbk_goods_info)中有100000种货物，以2000的倍数为值域的切分点，则各数据范围内的记录条数是相等的，此种分布称为平均分布。或数据类型如此，则要计算某个查询条件的选择性是否很高就相当的容易且精准。
如果数据是标准分布的，也就是说数据在有些范围内多，有些范围内少，以这个例子来说，就是有些货物的销售记录很多，有些货物可能基本上没有销售记录，则该索引就需要有更细致的统计数据，以记录一个范围的数据约略有多少条记录，在查询优化程序判断某个索引是否适用某项查询时，才可以精确判断出该字段的选择性是否很高，以决定使用的索引。
这也就是当你观察Dbcc show_statistics时(如上图)，如果呈现的分布记录有很多条，表示该键值在整个记录中是标准分布，所以需要各区段的记录数目，以较为精确地判断符合条件的记录数多少，若只有寥寥三四笔，表示接*均分布，只需要描述平均分布的状态即可。
第四、索引的有效性
在根据以上三原则建立相应的索引之后，我们再来看看如何观察在建立索引后，查询语句是否变得较有效率，索引的使用效率是否高。
--没有索引的情况
Set statistics io on
Select [WBOOK_NO] ,[COP_G_NO] ,[G_NO]
,[CONTR_ITEM] ,[CODE_S] ,[CODE_T]
,[G_NAME] ,[G_MODEL] ,[G_QTY] ,[G_UNIT] ,[QTY_1] ,[UNIT_1] ,[TRADE_CURR] ,[DECL_PRICE] ,[TRADE_TOTAL] ,[GROSS_WT] ,[NET_WT] from WBK_PDE_LIST_ORG_HISTROY c
Where c.WBOOK_NO='BE404942450001' and c.COP_G_NO='60196928' and QTY_1>15
Select * from sys.dm_db_missing_index_groups
Select * from sys.dm_db_missing_index_group_stats
Select * from sys.dm_db_missing_index_details
Select mig.*,statement as table_name,column_id,column_name,column_usage
From sys.dm_db_missing_index_details as mid
Cross apply sys.dm_db_missing_index_columns (mid.index_handle)
Inner join sys.dm_db_missing_index_groups as mig on mig.index_handle=mid.index_handle
Order by mig.index_group_handle,mig.index_handle,column_id
---在建立索引之后，再次执行以上语句。
接下来通过sys_dm_db_index_usage_stats可观察是否生成了过多的索引。
--插入数据会影响到索引
insert WBK_PDE_LIST_ORG_HISTROY
Select 'BE404942451001','60196928','11427','305','92','52083200'
,null ,'布料',null,'215',25,'011',25,'011',null,null,null,10.82,270.5,null,null,null,5,3.8
表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数0，逻辑读取17 次，物理读取5 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
--更新数据会影响到索引
--通过PK_WBK_PDE_LIST_ORG_HISTROY
--idx_WBK_PDE_LIST_QTY1
--idx_WBK_PDE_LIST_COP_G_NO索引扫描WBOOK_NO='BE404942451001'的记录
update WBK_PDE_LIST_ORG_HISTROY set QTY_1=50000
where WBOOK_NO='BE404942451001'
--表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取9 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
Select * from sys.dm_db_index_usage_stats where object_id=object_id('WBK_PDE_LIST_ORG_HISTROY')
图1，索引使用情况分布图 
图2，索引名称
从上图1中可以看到 sys.dm_db_index_usage_stats系统视图是指某个查询利用索引所进行的查找、扫描、查找或更新操作都被计为对该索引的一次使用，每次使用都会对视图中的相应计数器累加1。它针对用户提交的查询所导致的操作，以及由系统内部产生的查询所导致的操作（例如，扫描以收集统计数据）分开累积信息。而由于前述的insert语句会影响到之前建立的所有索引，所以index_id等于1、6、10的记录行的user_updates字段为是1 （见图1中2）。update 语句会更新数据表中的QTY_1字段，但是没有更新COP_G_NO字段，所以只影响index_id等于1与6的记录行，这两行的user_updates字段是2（见图1中3）。update语句的where条件则会利用index_id等于1的索引，见user_seeks的值为1（见图1中3）。
User_updates字段是指由于基础数据表或视图的插入、更新或删除操作导致的更新次数。利用这个数据可判断应用程序是否很少用到某个索引。如果该索引的更新次数(user_updates)值很大，那么说明产生的维护量比较大，再参见搜索次数(user_seeks)与书签查找操作的次数(user_lookups)，如是这两个值很小，则可以考虑删除索引。
重新启动SQL SERVER服务时，sys.dm_db_index_usage_stats系统视图内的各种计数器会初始化为空值。此外，每当分离或关闭数据时（例如，由于 AUTO_CLOSE 设置为 ON），就会删除所有与该数据库关联的数据行。初次使用某个索引后，才会加入到系统的统计信息中，sys.dm_db_index_usage_stats随后才看得到代表该索引的数据行，此时各项计数器的初始设置值为零。
最后再次重申一下，“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
所以说，我们要建立一个“适当”的索引体系，特别是对聚集索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。
因为非聚集索引需要在非聚集索引的B树中找到每一行的指针，再去其所在表上找数据，性能因此会大打折扣，有时甚至不如不加非聚集索引。