SQL Server索引设计与调优SQL Server索引技巧设计与调优如果你想极大提高SQL Server性能，本篇指南中提到的索引将是您最佳选择之一。

在本文指南中你将了解如何设计最佳SQL Server索引、如何调整SQL Server索引等一系列内容，让你现存的SQL Server索引能够发挥最佳效能。

SQL Server索引设计SQL Server集簇索引的设计SQL Server中集群索引设计对SQL Server数据库系统性能和未来的维护十分重要。

在本文中你将了解到为什么集群索引应该是静态、随着时间推移而增长、了解它们是如何使用多对多表的。

此外，在文中你还会知道在SQL Server 2005中分区表概念是怎样影响集群索引的。

设计SQL Server集簇索引以提升性能（一）设计SQL Server集簇索引以提升性能（二）如何创建SQL Server索引索引的作用应该是确保主要性能。

本节你将会学到如何清除那些没有价值的索引并识别推荐索引保证你的SQL Server索引能发挥它的最大效能。

SQL Server索引创建技巧（上）SQL Server索引创建技巧（下）如何优化索引索引SQL Server数据库既是艺术也是技术。

我们必须根据设计和编码来选择正确的索引。

但是，当测试索引设计时，我们可能发现它对系统性能的提高并没有达到我们的要求。

我们必须通过学习索引字段、聚簇索引、主键以及索引配置来创建最佳设计的SQL Server索引。

文中介绍了一些设计索引时的常见问题。

专家详解SQL Server 2000创建和优化索引索引的能与不能在这一系列的问题和答案中，我们将了解索引列和数据库的正确含义，避免出现页面拆分的情况并了解SQL Server 2000的能与不能。

SQL Server 2000索引的能与不能（DO和DON’T）改进性能的分区索引SQL Server 2005索引分区允许你将特定索引符合分散到多个文件。

本文中还介绍了如何用分区数据创建索引的方法。

改进SQL Server 2005性能的分区索引（上）改进SQL Server 2005性能的分区索引（下）聚簇索引和非聚簇索引的区别什么时候使用聚簇索引或非聚簇索引呢？回答这个问题有点难度，坦白地说，我即将给出的答案是一个流传已久的标准数据库管理员的回答：“具体问题具体分析”。

有大量因素影响何时以及何地进行索引创建。

幸好只有两个选择，但分析这两个选择的优缺点都相当复杂。

SQL Server中的聚簇索引和非聚簇索引（一）SQL Server中的聚簇索引和非聚簇索引（二）SQL Server非聚簇索引设计非聚簇索引是书签，它们让SQL Server找到我们所查询的数据的访问捷径。

非聚簇索引是很重要的，因为它们允许我们只查询一个特定子集的数据，而不需要扫描整个表。

对于这个重要主题的探讨，我们首先从了解基础开始，比如，聚簇索引与非聚簇索引如何互相作用，如何选择域，何时使用复合索引以及统计是如何影响非聚簇索引的。

设计查询优化的SQL Server非聚簇索引（上）设计查询优化的SQL Server非聚簇索引（下）如何添加非聚簇索引增加非聚簇索引到我们经常要查询的SQL Server列表是很有可能的。

本文就介绍了这方面的知识。

添加非聚簇索引到SQL Server字段创建索引的更好办法为文本数据（varchar、nvarchar、char等）创建索引是一种很好的实现更快数据查询的方法。

然而，这些索引会给存储索引的磁盘以及服务器内存带来压力。

这是因为索引上存有大量的数据。

为文本数据创建索引的更好方法SQL Server索引调优SQL Server Index Tuning Wizard的使用技巧回答如何全面提高SQL Server 2000性能、如何使用SQL Server Index Tuning Wizard技巧更好地理解基本数据库索引。

SQL Server Index Tuning Wizard的使用技巧处理SQL Server 2000索引碎片技巧当遇到数据库的性能问题时，其中一个最大的性能提升方法可以通过优化索引来实现。

索引可以改善数据访问，这样我们就不需要扫描整个表，因为这会消耗大量的CPU、IO和内存资源。

随着时间的推移，索引可能会产生碎片，从而导致SQL Server性能下降、事务时间处理时间变长、阻塞和低吞吐量。

处理SQL Server 2000索引碎片技巧（一）处理SQL Server 2000索引碎片技巧（二）处理SQL Server 2000索引碎片技巧（三）最佳SQL Server索引策略恰当的索引能创建完全不同的性能。

对于大多数的数据类型，SQL Server只支持两种索引类型——聚簇索引和非聚簇索引。

同时，SQL Server也支持全文索引和XML索引，但是它们只与特定数据类型相关。

最佳SQL Server索引策略维护SQL Server索引以实现查询优化维护SQL Server索引是一个不寻常的实践。

如果查询不使用索引，那么往往会有一个新的非聚簇索引被创建，它只是包含一个不同的或是相同的字段组合。

但现在并没有发布一个关于为什么SQL Server会忽略这些索引的详细分析。

如何维护SQL Server索引以实现查询优化（一）如何维护SQL Server索引以实现查询优化（二）如何维护SQL Server索引以实现查询优化（三）SQL Server中用于查找索引碎片的存储过程由于数据修改，SQL Server表和索引会逐渐出现数据碎片。

在大型的I/O操作中，在SQL Server中用到这些碎片索引和表，可能对应用性能产生不利影响。

SQL Server中用于查找索引碎片的存储过程（上）SQL Server中用于查找索引碎片的存储过程（下）设计SQL Server集簇索引以提升性能（一）SQL Server的集簇索引是数据库整体架构的一个非常重要的方面。

它们经常被忽视、误解，或者如果数据库很小，它们会被认为是不重要的。

本文阐述了集簇索引对于整个系统性能以及数据库增大时维护的重要性。

我将主要说明SQL Server集簇索引是如何存储在硬盘中的，为什么它们应该一直随着时间增加以及为什么静态的集簇索引是最好的。

我同时也将探讨多对多表，为什么它们会被使用，以及集簇索引如何能够让这些表效率更高。

最后，很重要的是我们会讨论新的SQL Server 2005分割表概念，并探讨分割表是如何影响集簇索引的。

这将有助于你以后作为出正确的决定性。

集簇索引默认是与匹配主键相匹配的，而主键是定义在SQL Server表上的。

然而，你可以在任何字段上创建一个集簇索引，然后在另一个字段或多个字段上定义一个主键。

这时，这个主键将会作为一个唯一的非集簇索引被创建。

典型地，一个集簇索引会与主键相匹配，但这并不是必须的，所以要仔细考虑。

对于各种可能出现的情况，我将讨论集簇索引本身，而不管你是否选择将它与主键相匹配。

集簇索引实际上装载了SQL Server的数据记录行，所以你的集簇索引存储的地方就是你的数据存储的地方。

集簇索引是按数据范围而组织的。

比如，1到10之间的值存储为一个范围，而90到110是另一个范围。

因为集簇索引是按范围存储的，如果你需要在一个范围中搜索一个审计日志，使用基于日期字段的集簇索引效率会更高，其中日期字段会用于返回日期范围。

非集簇索引更适用于具体值的搜索，比如“等于DateValue的日期”，而不是范围搜索，比如“在date1和date2之间的日期”。

集簇索引的不断增加值集簇索引必须是基于值不断增加的字段。

在前面的例子中，我使用了审计日志的日期字段，审计日志的日期值是不断增加的，而且旧的日期将不会再插入到数据表中。

这就是一个“不断增加”字段。

另一个不断增加值的好例子就是标识字段，它也是从创建后就持续恒定增加的。

为什么我在这里花这么多时间讨论集簇索引的不断增加值呢？这是因为集簇索引的最重要的属性就是它们是不断增加的并且本质上是静止的。

不断增加之所以重要的原因与我之前提到的范围架构有关。

如果值不是不断增加的，SQL Server就必须在现有记录的范围内分配位置，而不是直接将它们放到索引后面的新的范围中。

如果值不是不断增加的，那么当范围的值用完后再出现一个已经用索引范围的值时，SQL Server将做一个页拆分插入一个索引。

在实现时，SQL Server会将已填满的页拆分成两个单独的页，这两个页此时会有更多的值空间，但这需要更多的资源去处理。

你可以通过设置填充参数为70%来作好预备工作，这样就可以有30%的自由空间来为后来的值使用。

这个方法的问题是你必须不断地“再索引”集簇索引使它能维持30%的自由空间。

对集簇索引进行再索引会带来繁重的I/O负载，因为它必须移动它的实际数据，并且任何非集簇索引都必须重建，这会增加许多的维护时间。

如果集簇索引是不断增加的，你将不需要重建集簇索引。

你可以将集簇索引的填充因数设置为100%，这样随着时间的推移，你就只需要对于不集中的、非集簇索引进行再索引，这样就可以增加数据库在线时间。

不断增加的值将只会在索引的尾部添加新值，并且只在需要的时候才创建新的索引范围。

由于新的值都只会不断地添加到索引的尾部而且填充因数为100%，所以将不再会有逻辑碎片出现。

填充因数越高，每一页所填充的记录行就越多。

更高的填充因数使得查询时会需要更少的I/O、RAM和CPU资源。

你查询集簇索引中越少的数据类型，JOIN/查询操作速度会更快。

同时，因为每一个非集簇索引都要求包括集簇索引键，所以集簇索引键和非集簇索引也会更小。

集簇索引的最佳数据类型是非常狭窄的。

对于数据类型大小，它通常是smallint、int、bigint或datetime。

当datetime值用作集簇索引时，它们是唯一的字段并且通常是不断增加的日期值，这些值通常是作为范围数据查询的。

通常，你应该避免组合（多字段）集簇索引，除了以下情况：多对多数据表和SQL Server 2005分割表，这种分割表有分割的字段，它包含了集簇索引而允许索引排列。

(作者：Matthew Schroeder 译者：陈柳/曾少宁 来源：TT中国)这个方法的一个缺点是CustomerOrder表的碎片（不是连续的）。

然而，这并不是一个大问题，因为这个表是相对较小的，它只有2个字段，数据类型也很少，并且只有一个集簇索引。

这些本来是在包括CustomerID的Orders表的非集簇索引的减少，带来的好处是大于额外开销的。

SQL Server 2005的集簇索引和分割表SQL Server 2005中的分割表是一些表面上为一个独立的表，但实际上——在存储子系统中——它们包含能够存储在许多文件组（Filegroup）的多个部分。