SQL Server索引设计和调优技巧大全

SQLServer索引设计与调优SQLServer索引技巧设计与调优如果你想极大提高SQLServer性能，本篇指南中提到的索引将是您昀佳选择之一。在本文指南中你将了解如何设计昀佳SQLServer索引、如何调整SQLServer索引等一系列内容，让你现存的SQLServer索引能够发挥昀佳效能。SQLServer索引设计SQLServer集簇索引的设计SQLServer中集群索引设计对SQLServer数据库系统性能和未来的维护十分重要。在本文中你将了解到为什么集群索引应该是静态、随着时间推移而增长、了解它们是如何使用多对多表的。此外，在文中你还会知道在SQLServer2005中分区表概念是怎样影响集群索引的。™设计SQLServer集簇索引以提升性能（一）™设计SQLServer集簇索引以提升性能（二）如何创建SQLServer索引索引的作用应该是确保主要性能。本节你将会学到如何清除那些没有价值的索引并识别推荐索引保证你的SQLServer索引能发挥它的昀大效能。™SQLServer索引创建技巧（上）™SQLServer索引创建技巧（下）如何优化索引TT数据库技术专题之“SQLServer索引设计指南”Page2of71索引SQLServer数据库既是艺术也是技术。我们必须根据设计和编码来选择正确的索引。但是，当测试索引设计时，我们可能发现它对系统性能的提高并没有达到我们的要求。我们必须通过学习索引字段、聚簇索引、主键以及索引配置来创建昀佳设计的SQLServer索引。文中介绍了一些设计索引时的常见问题。™专家详解SQLServer2000创建和优化索引索引的能与不能在这一系列的问题和答案中，我们将了解索引列和数据库的正确含义，避免出现页面拆分的情况并了解SQLServer2000的能与不能。™SQLServer2000索引的能与不能（DO和DON’T）改进性能的分区索引SQLServer2005索引分区允许你将特定索引符合分散到多个文件。本文中还介绍了如何用分区数据创建索引的方法。™改进SQLServer2005性能的分区索引（上）™改进SQLServer2005性能的分区索引（下）聚簇索引和非聚簇索引的区别什么时候使用聚簇索引或非聚簇索引呢？回答这个问题有点难度，坦白地说，我即将给出的答案是一个流传已久的标准数据库管理员的回答：“具体问题具体分析”。有大量因素影响何时以及何地进行索引创建。幸好只有两个选择，但分析这两个选择的优缺点都相当复杂。TT数据库技术专题之“SQLServer索引设计指南”Page3of71™SQLServer中的聚簇索引和非聚簇索引（一）™SQLServer中的聚簇索引和非聚簇索引（二）SQLServer非聚簇索引设计非聚簇索引是书签，它们让SQLServer找到我们所查询的数据的访问捷径。非聚簇索引是很重要的，因为它们允许我们只查询一个特定子集的数据，而不需要扫描整个表。对于这个重要主题的探讨，我们首先从了解基础开始，比如，聚簇索引与非聚簇索引如何互相作用，如何选择域，何时使用复合索引以及统计是如何影响非聚簇索引的。™设计查询优化的SQLServer非聚簇索引（上）™设计查询优化的SQLServer非聚簇索引（下）如何添加非聚簇索引增加非聚簇索引到我们经常要查询的SQLServer列表是很有可能的。本文就介绍了这方面的知识。™添加非聚簇索引到SQLServer字段创建索引的更好办法为文本数据（varchar、nvarchar、char等）创建索引是一种很好的实现更快数据查询的方法。然而，这些索引会给存储索引的磁盘以及服务器内存带来压力。这是因为索引上存有大量的数据。™为文本数据创建索引的更好方法TT数据库技术专题之“SQLServer索引设计指南”Page4of71SQLServer索引调优SQLServerIndexTuningWizard的使用技巧回答如何全面提高SQLServer2000性能、如何使用SQLServerIndexTuningWizard技巧更好地理解基本数据库索引。™SQLServerIndexTuningWizard的使用技巧处理SQLServer2000索引碎片技巧当遇到数据库的性能问题时，其中一个昀大的性能提升方法可以通过优化索引来实现。索引可以改善数据访问，这样我们就不需要扫描整个表，因为这会消耗大量的CPU、IO和内存资源。随着时间的推移，索引可能会产生碎片，从而导致SQLServer性能下降、事务时间处理时间变长、阻塞和低吞吐量。™处理SQLServer2000索引碎片技巧（一）™处理SQLServer2000索引碎片技巧（二）™处理SQLServer2000索引碎片技巧（三）昀佳SQLServer索引策略TT数据库技术专题之“SQLServer索引设计指南”Page5of71恰当的索引能创建完全不同的性能。对于大多数的数据类型，SQLServer只支持两种索引类型——聚簇索引和非聚簇索引。同时，SQLServer也支持全文索引和XML索引，但是它们只与特定数据类型相关。™昀佳SQLServer索引策略维护SQLServer索引以实现查询优化维护SQLServer索引是一个不寻常的实践。如果查询不使用索引，那么往往会有一个新的非聚簇索引被创建，它只是包含一个不同的或是相同的字段组合。但现在并没有发布一个关于为什么SQLServer会忽略这些索引的详细分析。™如何维护SQLServer索引以实现查询优化（一）™如何维护SQLServer索引以实现查询优化（二）™如何维护SQLServer索引以实现查询优化（三）SQLServer中用于查找索引碎片的存储过程由于数据修改，SQLServer表和索引会逐渐出现数据碎片。在大型的I/O操作中，在SQLServer中用到这些碎片索引和表，可能对应用性能产生不利影响。™SQLServer中用于查找索引碎片的存储过程（上）™SQLServer中用于查找索引碎片的存储过程（下）TT数据库技术专题之“SQLServer索引设计指南”Page6of71设计SQLServer集簇索引以提升性能（一）SQLServer的集簇索引是数据库整体架构的一个非常重要的方面。它们经常被忽视、误解，或者如果数据库很小，它们会被认为是不重要的。本文阐述了集簇索引对于整个系统性能以及数据库增大时维护的重要性。我将主要说明SQLServer集簇索引是如何存储在硬盘中的，为什么它们应该一直随着时间增加以及为什么静态的集簇索引是昀好的。我同时也将探讨多对多表，为什么它们会被使用，以及集簇索引如何能够让这些表效率更高。昀后，很重要的是我们会讨论新的SQLServer2005分割表概念，并探讨分割表是如何影响集簇索引的。这将有助于你以后作为出正确的决定性。集簇索引默认是与匹配主键相匹配的，而主键是定义在SQLServer表上的。然而，你可以在任何字段上创建一个集簇索引，然后在另一个字段或多个字段上定义一个主键。这时，这个主键将会作为一个唯一的非集簇索引被创建。典型地，一个集簇索引会与主键相匹配，但这并不是必须的，所以要仔细考虑。对于各种可能出现的情况，我将讨论集簇索引本身，而不管你是否选择将它与主键相匹配。集簇索引实际上装载了SQLServer的数据记录行，所以你的集簇索引存储的地方就是你的数据存储的地方。集簇索引是按数据范围而组织的。比如，1到10之间的值存储为一个范围，而90到110是另一个范围。因为集簇索引是按范围存储的，如果你需要在一个范围中搜索一个审计日志，使用基于日期字段的集簇索引效率会更高，其中日期字段会用于返回日期范围。非集簇索引更适用于具体值的搜索，比如“等于DateValue的日期”，而不是范围搜索，比如“在date1和date2之间的日期”。集簇索引的不断增加值TT数据库技术专题之“SQLServer索引设计指南”Page7of71集簇索引必须是基于值不断增加的字段。在前面的例子中，我使用了审计日志的日期字段，审计日志的日期值是不断增加的，而且旧的日期将不会再插入到数据表中。这就是一个“不断增加”字段。另一个不断增加值的好例子就是标识字段，它也是从创建后就持续恒定增加的。为什么我在这里花这么多时间讨论集簇索引的不断增加值呢？这是因为集簇索引的昀重要的属性就是它们是不断增加的并且本质上是静止的。不断增加之所以重要的原因与我之前提到的范围架构有关。如果值不是不断增加的，SQLServer就必须在现有记录的范围内分配位置，而不是直接将它们放到索引后面的新的范围中。如果值不是不断增加的，那么当范围的值用完后再出现一个已经用索引范围的值时，SQLServer将做一个页拆分插入一个索引。在实现时，SQLServer会将已填满的页拆分成两个单独的页，这两个页此时会有更多的值空间，但这需要更多的资源去处理。你可以通过设置填充参数为70%来作好预备工作，这样就可以有30%的自由空间来为后来的值使用。这个方法的问题是你必须不断地“再索引”集簇索引使它能维持30%的自由空间。对集簇索引进行再索引会带来繁重的I/O负载，因为它必须移动它的实际数据，并且任何非集簇索引都必须重建，这会增加许多的维护时间。如果集簇索引是不断增加的，你将不需要重建集簇索引。你可以将集簇索引的填充因数设置为100%，这样随着时间的推移，你就只需要对于不集中的、非集簇索引进行再索引，这样就可以增加数据库在线时间。不断增加的值将只会在索引的尾部添加新值，并且只在需要的时候才创建新的索引范围。由于新的值都只会不断地添加到索引的尾部而且填充因数为100%，所以将不再会有逻辑碎片出现。填充因数越高，每一页所填充的记录行就越多。更高的填充因数使得查询时会需要更少的I/O、RAM和CPU资源。你查询集簇索引中越少的数据类型，JOIN/查询操作速度会更快。同时，因为每一个非集簇索引都要求包括集簇索引键，所以集簇索引键和非集簇索引也会更小。TT数据库技术专题之“SQLServer索引设计指南”Page8of71集簇索引的昀佳数据类型是非常狭窄的。对于数据类型大小，它通常是smallint、int、bigint或datetime。当datetime值用作集簇索引时，它们是唯一的字段并且通常是不断增加的日期值，这些值通常是作为范围数据查询的。通常，你应该避免组合（多字段）集簇索引，除了以下情况：多对多数据表和SQLServer2005分割表，这种分割表有分割的字段，它包含了集簇索引而允许索引排列。(作者：MatthewSchroeder译者：陈柳/曾少宁来源：TT中国)TT数据库技术专题之“SQLServer索引设计指南”Page9of71设计SQLServer集簇索引以提升性能（二）多对多表和集簇索引多对多表有非常快速的JOIN并允许快速的从一个记录到另一个记录的重新联合。设想有下面这样的数据结构：CustomerCustomerID(bigintidentity)NameFieldn+CustomerOrderCustomerIDOrderIDOrdersOrderID(bigintidentity)DateFieldn+这些结构中的集簇索引是CustomerID和OrderID。组合键是CustomerID/OrderID。下面这个结构的优点：zJOIN都是基于集簇索引（比非集簇索引JOIN快很多）。z将一个Order赋给另一个Customer只需要对CustomerOrder表作一个UPDATE操作，这是改动非常少的，只影响到一个集簇索引。因此，它减少了你在更新一个大表时的数据库锁的时间，如Orders表。z使用多对多表就不需要大表中的一些非集簇索引，如Customer/Orders。因此，它减少大表的维护时间。TT数据库技术专题之“SQLServer索引设计指南”Page10of71这个方法的一个缺点是CustomerOrder表的碎片（不是连续的）。然而，这并不是一个大问题，因为这个表是相对较小的，它只有2个字段，数据类型也很少，并且只有一个集簇索引。这些本来是在包括Custo