对于你的SQL Server索引来说，什么是最好的性能调优策略？

如果你希望将SQL Server实例的性能保持在最佳状态，并反过来为依赖它的任何软件解决方案的终端用户提供一致的体验，那么优化索引的方法就很重要。

这一点说起来容易，但在实践中却很难实现，除非你作为一个管理员有正确的策略和解决方案可以使用。

考虑到这一点，让我们来看看一些最好的工具和策略，以便在你调整和提高你的SQL Server索引的性能时将其用于工作。

剔除碎片并适当地处理它

良好的SQL Server索引分析的关键是研究随着时间的推移而形成的碎片水平，并找出你需要采取什么类型的行动来补救它。

碎片化是索引中的一种自然现象，因为当对表进行修改时，这意味着它们不那么准确，因此，如果不加以检查，处理查询的时间会更长。

这里有两条关键路线，其中一条是重组，另一条是完全重建索引。

正如你所期望的那样，重组索引对于较低水平的碎片化来说是比较好的，而如果它变得特别碎片化，则可能需要重建。后者在进行时对服务器性能的破坏性更大，所以很明显，这需要安排，以避免与使用的高峰期相吻合。

不同的管理员有不同的方法和参数来确定是否需要重组或重建索引，所以没有硬性规定你需要遵守。

然而，最佳做法是，如果碎片率低于30%，你可以直接重组索引以积极调整性能，而如果它超过这个上限，重建会更好。

有了合适的SQL Server监控工具在手，你可以很容易地保持对索引碎片问题的关注，甚至可以在出现特定情况时自动重组或重建索引，或者仅仅依靠警报来跟踪，并在必要时实施行动。

一般来说，SQL Server表上的索引能够提高性能，因为它允许查询获得他们需要的条目，而不必每次执行时都要搜索整个条目。

你通常会选择为一个表添加多个索引，以满足通常使用的特定类型的查询。这是一个进一步优化性能的好方法，可能是你已经在做的事情。

然而，在研究正在使用的索引数量时，需要考虑到几个问题。首先，表被更新或以任何方式改变的频率问题，其次，表的大小和规模问题。

对于那些最经常被访问的表来说，在任何时候都有较少数量的索引在发挥作用，这可能是更理想的做法，因为你每增加一层，都意味着查询必须跳过更多的障碍才能执行。

相反，对于那些偶尔被访问的表，你可以有更多更专业的索引，每个索引都被调整为覆盖一个特定的查询，你知道在某些时候会使用它。

如前所述，大小也很重要，虽然大表如果有索引的话，性能肯定会更好，但如果一个表只填充了很少的条目，那么索引实际上会成为一个减速器。

再一次，你需要看看你的SQL服务器的具体需求和依赖它的应用程序的类型，以确定这里的最佳行动方案。假设你现在所做的事情已经足够了，这是没有意义的，因为即使对你的索引策略进行小的优化，也可以带来很大的好处。

无论你如何仔细地实施和监控SQL Server索引，如果你没有掌握编写查询的最佳实践，你仍然可以期待性能达到最佳状态。

无论你的查询是松散的，包含了太多的组件和指令，还是不精确的，包含了比严格意义上所需的更多的表项，回到基础并审查这些，也会让你深入了解你的索引是否也被正确地利用了。

由此，你将能够进一步确定你选择的索引是否与它们需要随时处理的操作相一致。它们可能面向一种类型的查询，但却为另一种类型的查询制造了一个绊脚石。

这有点像需要同时看到微观和宏观，认识到改变SQL Server设置的单独部分可能会在其他地方产生连锁反应，无论是在提高性能还是阻碍性能方面。

我们已经讨论过，在索引优化和查询编写方面，你需要研究什么是最适合你的SQL Server的，但这并不意味着你应该僵硬地遵循你认为正确的道路，面对相反的证据。

由于你可以持久地监控你的服务器，并跟踪性能如何随时间变化，你可以使用这些信息来分析和排列你所做的任何改变，这反过来应该告诉你是否需要进一步调整，或者你是否在正确的轨道上。

灵活并愿意改变，以及对性能问题保持警惕，将使你更经常地从你的SQL服务器中获得最佳性能。