查询调优应该是主动还是被动？

作为软件开发人员和有抱负的DBA，我在设计SQL Server数据库时尝试结合最佳实践（我的软件有99％的时间位于SQL Server之上）。在开发之前和开发过程中，我会做出最好的设计。

但是，就像其他任何软件开发人员一样，这里添加了功能，错误以及对需求的更改，这些需求要求更改/创建的数据库对象。

我的问题是，查询调优应该是主动还是被动？换句话说，在对代码/数据库进行大量修改之后的几周内，我是否应该留出一天时间检查查询性能并据此进行调整？即使看起来运行正常吗？

还是我应该意识到，性能低于平均水平的应该是数据库检查并回到众所周知的黑板上？

查询调优可能会花费大量时间，并且取决于最初的数据库设计，它可能带来的收益很小。我对接受的作案手法感到好奇。

两者都有，但大多是主动的

在开发过程中测试实际数量和数据质量非常重要。在开发人员的100或1000行上运行查询，然后将其与1000万生产行放在一起，这是令人难以置信的普遍现象。

它也使您可以对“索引可能在这里有所帮助”进行注释。或“重温我”。或“将在下一个数据库版本中用新功能xxx修复”。

但是，一些查询无法经受时间的考验。由于优化程序决定使用其他联接类型，因此数据分布发生变化或呈指数级增长。在这种情况下，您只能做出反应。

说，至少对于SQL Server，各种“丢失索引”和“最长查询” DMV查询可以在电话呼叫之前指示问题区域

编辑：澄清...

主动并不意味着现在就调优每个查询。这意味着将您需要（经常运行）的内容调整到合理的响应时间。大多数情况下，请忽略每周三凌晨星期日的报告查询。

好吧，我咬一口，并采取相反的态度。首先，我要说的是，您不应该从做某件事开始就知道自己会导致麻烦。如果您想称其为应用最佳实践，请继续。这应该是积极主动的。

在那之后，时间（和金钱）浪费了，因此继续进行并交付您的产品。不用花费大量的设计时间来调优可能会或永远不会成为瓶颈的查询，而是将这段时间用于额外的测试，包括负载测试。

当您发现某些性能未达到您的设计规格要求，或者某些性能下降到探查器响应时间列表的底部10％或20％时，请花时间调整所需的时间破碎。

在一个完美的世界中，一切都将从一开始就进行完美的设计，并使用逻辑构建顺序进行开发。在现实世界中，预算和时间受到限制，您的测试数据可能最终看起来不像您的生产数据。出于这个原因，我说要用常识来主动避免问题，而是集中有限的资源来调整原来是真正的问题，而不是花时间和金钱去寻找想象中或潜在的问题。

您将要进行3种类型的调整，其中1种是被动调整，而2种是主动调整。

反应性

突然，一些查询开始引起您的问题。可能是由于应用程序错误或功能，表增长超出预期，流量高峰或查询优化器变得“创意”。这可能是午夜时分，现场的糟糕事件，或者可能是由于系统响应速度缓慢而引起的。无论哪种方式，反应性调整的定义特征是您已经遇到了问题。不用说，您想要做的越少越好。这带我们去...

积极主动

类型1：例行维护

按照某种时间表，每隔几个月或几周，这取决于架构更改的频率和数据增长的速度，您应该查看数据库性能分析工具的输出（例如，针对Oracle DBA的AWR报告）。您正在寻找初期问题，这些问题正在要求进行响应式调整，以及低落的成果，这些项目不太可能很快引起问题，但可以通过很少的努力加以改进，以期避免出现严重问题。 -未来的问题。您应该花多少时间取决于您有多少时间以及可能要花费的时间，但是最佳金额永远不会为零。但是，您可以通过执行以下操作轻松减少需要花费的金额：

类型2：适当的设计

克努斯（Knuth）反对“过早优化”的告诫广为人知，并得到应有的尊重。但是必须使用“过早”的正确定义。一些应用程序开发人员在被允许编写自己的查询时，倾向于采用他们遇到的第一个查询，这在逻辑上是正确的，并且不关心性能，当前或将来。或者他们可能会针对根本不能代表生产环境的开发数据集进行测试（提示：请勿这样做！开发人员应始终可以访问实际数据进行测试。）。关键是，调整查询的正确时间是第一次部署查询时，而不是在性能不佳的SQL列表中显示查询时，而不是在导致严重问题时才进行调整。

那么，什么可以作为DBA领域中的过早优化呢？在我的清单中，最重要的是无需证明需要就可以标准化。当然，您可以在父行中维护总和，而不是在运行时从子行中计算总和，但是您真的需要吗？如果您是Twitter或Amazon，战略性反规范化和预先计算可能是您最好的朋友。如果您要为5个用户设计一个小型记帐数据库，则必须优先考虑适当的结构以促进数据完整性。其他过早的优化同样是优先事项。即使您认为您可以将查询的时间缩短到0.1秒，也不必花费数小时来调整每天运行一次且耗时10秒的查询。也许您有一个每天运行6个小时的报告，但在投入时间进行调整之前，请探索将其作为批处理作业进行计划。如果您的生产负载永远不会超过10％（假设您可以管理安全性），则不要投资单独的实时复制报表实例。

通过针对实际数据进行测试，对增长和流量模式进行有根据的猜测（加上峰值的余量），并运用您对平台优化程序怪癖的知识，您可以部署不仅在现在而且在将来以最佳状态运行的查询，并且条件不理想。当您应用适当的技术时，可以准确地预测和优化查询性能（就每个组件而言，其速度应与所需的一样快）。

（同时，您还可以学习统计信息！）

在理想环境中，所有调优都将在设计阶段主动完成，并且没有任何反应，但是环境并不完美。您会发现测试数据有时不具有代表性，测试用例将被遗漏，负载会意外地不同，并且会存在导致性能问题的错误。这些情况可能需要进行一些被动调整，但这并不意味着首选被动调整。目标应该始终是赶上这些。

您的追溯调整计划非常实用。在测试时，您应记录预期的时间安排和吞吐量，有时应实际进行分析，以使您知道生产过程何时不符合设计规范。通过这种方式，您可以预先确定需要调整的代码。然后，您不仅可以确定问题所在，还可以确定为什么在设计/测试阶段没有发现问题。

对我而言，性能测试一直是开发过程的一部分。是否要更改此表，更改此报告，添加此功能？在测试过程中，请确保您可以将单个和整体性能与已知基准和/或要求进行比较（例如，某些报告在后台运行或以其他方式自动运行，因此，系统并不总是最重要的）。

恕我直言，这根本不应该是一个反应性的过程-您永远不要等到变更导致生产中的性能问题开始对此作出反应。当您在dev / test等中进行更改时，您应该在具有相同应用程序和相似使用模式的相似硬件上使用相似数据来测试这些更改。不要让这些更改匆匆投入生产并使您感到惊讶。当花一天的时间不方便调校时，几乎总是会发生这种情况-请提前为该调校时间做好预算。