索引设计是数据库设计中比较重要的一个环节，对数据库的性能其中至关重要的作用，但是索引的设计却又不是那么容易的事情，性能也不是那么轻易就获取到的，很多的技术人员因为不恰
当的创建索引，最后使得其效果适得其反，可以说“成也索引，败也索引”
本系列文章来自Stairway to SQL Server Indexes，翻译和整理发布在agilesharp和博客园，希望对广大的技术朋友在如何使用索引上有所帮助。
在本篇文章中，我们在学习了之前的知识之后，推荐14条指导方针。这14条指导方针可以帮助你更好的为数据库构建索引。
本篇文章的格式使用了由Addison Wesley出版社出版的<Framework Design Guidelines>中使用的格式。每一个最佳实践之前都使用了如下4个动词：要，考虑，避免、不要，分别
代表如下意思:
要(Do):这个原则要坚决遵守
考虑(Consider):通常情况下都要遵循这个原则，但如果你对原则背后的原理有了深入了理解，可以根据实际情况不采用这个原则
避免(Avoid):考虑的反义词,意味着避免做某这类事，但同样，如果你了解了背后的原理，则可以根据实际情况做这类事。
不要(Do Not)：避免的增强版,意思是无论什么时候都不要做这类事。
指导方针
要了解跑在数据库上的应用程序/用户
使用索引的主要目的是为了提高跑在数据库上应用程序读取和操作数据的速度，如果你不知道程序主要对数据库进行什么操作，索引优化就无从谈起。
当然，如果你全程参与了程序的设计和开发，那再好不过。但这种情况少之又少，大多数情况都是你直接接手数据库和应用程序，这时你就需要两步走的了解你所接手的东西-通过外部和
内部。
外部方法包括从用户那里了解程序相关的信息，观察他们使用程序的过程，阅读用户文档和交接文档。
内部方法是去看程序本身对数据库产生的操作。比如说Activity Monitor, Profiler等工具，也可以使用sys.dm_db_index usage_stats和sys.dm_db_missing_index_XXX系列
DMV中找到所需信息，这些信息包括用的最多的查询，用的最多的索引，用的少的索引以及本应建却没有建的索引。
通过找到拖累系统性能的查询，比如报表服务中用到的语句，agent中执行的T-SQL，SSIS中执行的T-SQL以及存储过程。找到这类信息就可以知道优化该从何处下手。
得到上面的信息后，就可以知道哪些索引应当存在，哪些索引应该删除。
不要过度创建索引
过多的索引和太少的索引都不是好事。表中该有多少索引可不是一个固定的数字。当你为主键，候选键和外键建立了索引之后，剩下的索引该怎么建就需要谨慎分析后再做定夺了。
要明白这点:同样的数据库在不同的环境下要有不同的索引
在忙时或是闲时；在OLTP环境或是OLAP环境下，所需要的索引是不同的。
比如每天晚上一次性大量更新数据的报表数据库在这时只需要少量索引，而在日间忙时则需要大量索引。数据库上跑少量查询要比数据库跑大量查询需要更少的索引。
要给每个表设置主键
虽然SQL Server并不强制要求设置主键。但一个没有主键的表无论在OLTP还是OLAP环境下都是一件危险的事，因为没有主键就不能保证每行是唯一的。这时你就无法知道同一行数据
是否在表中存在两条，尤其是在你还没有足够的信息去分析这点时。
尽管SQL Server不强制要求设置主键，但主键是关系数据库的一个关键理论。如果没有主键约束，那么与之关联的唯一索引或是连接操作就
