SQL Server最佳索引策略

        SQL Server为大多数数据类型只提供了两种索引类型——聚簇和非聚簇。SQL Server也支持全文检索索引和XML索引，但这些只对特定的数据类型。

　　为你的聚簇索引选择合适的列或列的集合是很关键的。因为表的数据物理上是按聚簇索引列的值排序的。你可以在每一个表上只创建一个单独的聚簇索引。非聚簇索引参照聚簇索引键(数据值)来决定每条记录的物理位置。

　 　建议你在不经常改变而要经常查询和具有较少数据类型的列上创建聚簇索引。在很多情况下，在序号列上建聚簇索引是最好的选择，因为序号值是被经常查询的 ——每条记录有一个唯一的序号值——并且它们从来不更新，而且是用SMALLINT，INT或BIGINT数据类型创建的。

　　然而一个基于它的序号列的表从来没有被查询过的情况也不罕见。如果这样，要仔细考虑数据一般是怎样获取的，也许是通过一个外键关联到另一个表，或者是通过一个特征列。通常，你可以通过在获取数据时最经常使用的列或列的集合上创建聚簇索引来改进性能。

　 　一些开发人员喜欢创建复合聚簇索引。这些涉及几列，它们结合起来唯一标识每一条记录。这也许听起来是个很好的做法，因为序号列没有业务意义，但是其它的列——像聘用日期、部门名称和车辆识别号码——立即转化为应用用户可以理解的意思。然而，从性能的角度看，你应该避免采用复合聚簇索引。

　　再次，索引越少，SQL Server就能越快的扫描或搜索。你可能发现对于一个小的数据集，复合索引执行的相对要好些。但是随着用户数目的增长，你肯定会遇到问题。

　　在你看到建立恰当的索引所到来的性能优势之后，你可能会觉得你的工作结束了。但是随着数据的增加、修改和从数据库中删除，每个索引变得支离破碎。破碎程度越高，你的索引起的作用越低。现在你需要执行一个删除你的索引碎片的计划来保证它们的有效性。

　　在SQL Server的前一版本中，从大索引(表具有几百万行记录)中删除碎片经常要求停机。所幸SQL Server2005支持在线索引重建，这使得你的工作相对容易。但是记住，重建索引仍然要求tempdb数据库具有系统资源和空间。如果可能，安排在用户活动最少的时间段做索引维护。

　　这篇文章引自数据库性能规划。

　　SQL Server数据库设计师和管理员如果想使他们的应用从开始就运行的很好，那么他们有很多选择。为了确保很好的数据库性能，在设计阶段作好的选择是很重要的。在本期的SQL Server INSIDER杂志中，专家Baya Pavliashvili讨论了怎样决定数据库设计，从而优化性能。设计一个数据库包括适当的：

　　数据模型
　　数据类型
　　索引策略
　　代码模块
　　高可用性选项