索引的使用

     索引的使用并不需要显式使用，建立索引后查询分析器会自动找出最短路径使用索引.

     但是有这种情况.当随着数据量的增长，产生了索引碎片后，很多存储的数据进行了不适当的跨页，会造成碎片(关于跨页和碎片以及填充因子的介绍，我会在后续文章中说到)我们需要重新建立索引以加快性能:

     比如前面的test_tb2上建立的一个聚集索引和非聚集索引，可以通过DMV语句查询其索引的情况:

SELECT index_type_desc,alloc_unit_type_desc,avg_fragmentation_in_percent,fragment_count,avg_fragment_size_in_pages,page_count,record_count,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID('AdventureWorks'),OBJECT_ID('test_tb2'),NULL,NULL,'Sampled')

    我们可以通过重建索引来提高速度:

ALTER INDEX idx_text_tb2_EmployeeID ON test_tb2 REBUILD

    还有一种情况是，当随着表数据量的增大，有时候需要更新表上的统计信息，让查询分析器根据这些信息选择路径，使用:

UPDATE STATISTICS 表名

   那么什么时候知道需要更新这些统计信息呢，就是当执行计划中估计行数和实际表的行数有出入时:

使用索引的代价

    我最喜欢的一句话是”everything has price”。我们通过索引获得的任何性能提升并不是不需要付出代价。这个代价来自几方面.

    1.通过聚集索引的原理我们知道，当表建立索引后，就以B树来存储数据.所以当对其进行更新插入删除时，就需要页在物理上的移动以调整B树.因此当更新插入删除数据时，会带来性能的下降。而对于非聚集索引，当更新表后，非聚集索引也需要进行更新，相当于多更新了N（N=非聚集索引数量）个表。因此也下降了性能.

    2.通过上面对非聚集索引原理的介绍，可以看到，非聚集索引需要额外的磁盘空间。

    3.前文提过，不恰当的非聚集索引反而会降低性能.

    所以使用索引需要根据实际情况进行权衡.通常我都会将非聚集索引全部放到另外一个独立硬盘上，这样可以分散IO，从而使查询并行.

总结

     本文从索引的原理和概念对SQL SERVER中索引进行介绍，索引是一个很强大的工具，也是一把双刃剑.对于恰当使用索引需要对索引的原理以及数据库存储的相关原理进行系统的学习.