如何回答为什么突然需要索引或查询的问题

我是具有3年经验的初级DBA。我们的工作是微调查询或建议开发人员应重写特定代码或需要索引。

开发团队经常问的一个简单问题是：“昨天运行良好，突然发生了什么变化？” 我们将被要求检查基础设施方面。对任何问题的第一反应总是似乎是将最大的责任归咎于基础架构，这始终是首先要进行验证的事情。

我们应该如何回答开发团队的“已更改”问题？你们曾经遇到过同样的情况吗？如果是这样，请分享您的经验。

如何回答开发人员更改的问题？

这不仅是DEV的一个非常普遍的问题，它还适用于IT和业务中的每个团队。

发生了什么变化？==>可以通过事实和数字来回答。

事实参考例如

• 增加访问数据库的用户数量？
• 服务器配置参数是否有变化？
• 数据库维护-更新统计信息，未执行索引的重组/重建？因此，计划被错误地生成！
• 数据量增加了吗？
• 在网络方面进行了更改，对操作系统进行了修补，和/或为SQL Server部署了新的Service Pack或CU- 无需对应用程序业务周期进行完整的回归测试？
• 底层的SAN突然变慢了？

如果您要显示数据，则可以得出数字。例如 ：

• 在这种情况下，为服务器建立基准至关重要。因为您可以用可靠的数字来支持事实，所以这将减轻责任感。
• 开始使用DMV或sp_whoisactive向表中收集数据，以便在sql server重新启动后保留数据。

（您必须根据自己的环境和需求，收集数据的频率/收集哪些数据以及保留期长短进行锻炼）或（您可以购买第三方软件，例如sqlsentry或idera的诊断管理器，将为您完成上述工作）。

好吧，您可能会因为以下原因而得到不同的计划：

• 该计划可能由于以下原因而被逐出缓存：
  • 服务重启
  • 手动清除计划缓存
  • 服务重启或故障转移
  • 意外更改，例如某些sp_configure更改会刷新缓存
  • 对基础对象，索引，统计信息或其他依赖项的某些更改触发了重新编译
• 您可能会得到与其他用户或先前的调用不同的计划，因为：
  • 查询文本可能不相同（这包括区分大小写和空格，不用担心其他列，联接条件，过滤器等）
  • 该查询可以由具有不同设置选项的不同用户（或不同的默认模式，如果计划中的任何对象都没有完全限定的名称（包括模式））运行。
• 查询和计划可能相同，但是由于以下原因您可能会获得不同的性能：
  • 该计划是使用不同的参数进行缓存的，并且该计划对于当前参数集不是最佳的（通常称为“参数嗅探”）
  • 基于参数的数据量或仅由于其间的数据更改而导致的数据量显着不同
  • 数据已发生变化，足以改变最有效的数据访问方式，但不足以触发统计信息更新或重新编译（搜索升序关键问题以及自动统计算法）
  • 数据已从缓冲池中逐出，现在必须从磁盘读取
  • 满足查询所需的资源具有更高的并发性，阻塞性或其他压力

我在这里详细介绍了很多这些内容：

• “相同”查询的多个计划

如果这些程序在不同的环境中运行，那么我要在此处检查一系列内容：

• “相同”服务器的不同计划

另外，请务必牢记，创建索引或更改查询可能不是查询突然变得更好的直接原因-有时仅仅是因为这些更改确实生成了新计划和/或使已经存在的计划无效。

像往常一样，亚伦· 伯特兰德（Aaron Bertrand）和金（Kin）提供了出色的答案。但是，两个答案都包含一个公共线程。如果您对这两个答案进行分析，您都会发现XYZ不能像昨天那样正常工作的原因并不是您/他们/人X所做的事情。事情发生变化的原因是由于XYZ原因数据库决定做不同的事情。

数据库是一个活生生的实体。数据库将做出决策，并通过假设，统计数据和其他启发式工具的组合改变主意。这与大多数应用程序层编程有显着不同（机器学习是一个明显的例外）。

_{我将使用一些军事参考资料，因为我现在无法想到更好的东西。一个更一般的隐喻将被赞赏（没有双关语）。}

在大多数应用程序中，程序员充当钻取讲师。他们准确地告诉计算机做什么，以什么顺序执行，有时要持续多长时间。对数据库进行编程更像是充当指挥官。您可以从高层次告诉它您想要做什么，并在需要时提供一些指导。该数据库将根据低级军官和士官等当前情报，找出执行计划的最佳方式。

通过在其他程序员的脑海中清楚地表明这一区别，他们希望他们会开始看到您没有像他们在自己的环境中那样拥有专政权。您正在将数据库引导到解决方案，并且偶尔由于好或坏的原因而使数据库偏离轨道。提醒他们，最终与数据库偏离轨道无关紧要，但是我们可以做些什么来恢复它。

_{*我认识到“为什么”对于将来的预防，学习等非常有价值。但是，OP似乎正面临着来自那些不想学习或帮助解决问题的人们的抵制。}