译索引进阶（十七）： SQL SERVER索引最佳实践

Posted 2022-07-02 qianxingmu

在本章我们给出一些建议：贯穿本系列我们提取出了十四条基本指南，这些基本的指南将会帮助你为你的数据库创建最佳的索引架构。

这些指南的格式借鉴了 “框架设计指导”，Krzysztof Cwalina 和Brad Abramszai.NET 程序开发的标准化方面做了优秀的工作，并由Addison Wesley.出版发行。每一条建议都由如下词语定义：“DO”, ‘CONSIDER‘, "AVOID", "DO NOT", 它们表示了如下的意义：

•   DO: 这条建议应该总是被遵守。
•   CONSIDER: 一般说来这条建议需要被遵守，但是如果你完全理解了指南背后的原因，并深入了解你不遵守这条指南的理由，那么便可以适时的从这条指南上转移你的注意力。
•    AVOID: 与 CONSIDER相对的，一般来说这条指南建议了一些不应该被做的事情，但是，如果你完全理解了为什么它不应该被做，并且你也理解无论如何也要做它的原因， 那么， 就做它。
•  DO NOT 是 AVOID 的强化版本，它预示着绝对不要做的一些事。DO NOT 指南也应该总是被遵守。

 指南

   了解你的程序/用户

           一个索引最主要目的便是提高你的应用程序的数据收集和收据管理操作的性能，除非你知道这些操作是什么，否则你不可能会改进它们。

          在一开始就介入程序，参与到程序的设计和开发是很理想的。但是真实的情况并不总是那样。如果你正在继承一个已经实现了的数据库和应用程序，那么采取两个措施来保证你理解了你继承的东西，外部措施和内部措施。

         外部措施包括从你的用你那边学习，与他们交谈，观察你的用户使用应用程序，阅读任何面向用户的文档和指导，以及查阅现有的表格和报告。

         内部措施涉及了检查应用程序本身，既包含了程序的定义也包含了程序的执行。诸如此类的工具： Activity Monitor, Profiler, sys.dm_db_index usage_stats， sys.dm_db_missing_index_XXX 系列DMV均 提供了关于最常用的查询，运行时间长的查询，最常用的索引，无用的索引，本应存在但却不存在的索引信息。

        检查最常用的以及性能低下的查询的最初的位置，例如，报告服务模板，T-SQL工作步骤，SSIS中的T-SQL任务，以及存储过程，这样以便获取到为什么这些语句对于应用程序来说如此重要的原因。因而便可以被更好的优化。

       拥有了这些信息，你便能更好的做出决策，哪些索引是有益的，哪些却并无益处。

  不要过度索引

      太多的索引和太少的索引一样是个问题。对于一个表来说， 不存在神奇的“最佳索引数”，每张表都是不同的，然而，一旦你对主键进行了索引，任何候选键，可能的外键，以及任何潜在的索引在你添加到数据库之前都需要认真的分析。

 理解： 一样的数据库＋不同的情形 = 不同的索引

      不管是否是一个日常处理还是一个临时处理，不管是运行在OLTP数据库上的事务性处理，还是运行在同一 数据库的拷贝上的报告性处理，不同的情况需要不同的索引。

      一个每晚接受大量新数据注入的数据库在数据注入时应该比正常时间具有更少的索引数。一个具有有限查询需求的易变数据库比一个每晚更新一次的报告数据库需要更少的索引数，后者会处理复杂的报告生成逻辑。