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

Question

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

但是，就像任何其他软件开发人员一样，存在需要更改/创建的数据库对象的附加功能、错误和需求更改。

我的问题是，查询优化应该是主动的还是被动的？换句话说，在一些大量的代码/数据库修改几周后，我是否应该留出一天来检查查询性能并根据它进行调整？即使它似乎运行正常？

或者我应该知道低于平均水平的性能应该是数据库检查并回到众所周知的黑板？

查询调优可能会占用大量时间，并且取决于初始数据库设计，它可能是最小的好处。我对公认的作案手法感到好奇。

Answer 1

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

在开发过程中根据实际数据量和质量进行测试非常重要。让开发人员在 100 或 1000 行上运行查询然后在 1000 万行生产行上运行的情况令人难以置信。

它也允许您对“索引可能在这里有所帮助”做笔记。或“重访我”。或者“将在下一个 DB 版本中修复新功能 xxx”。

但是，一些查询经不起时间的考验。由于优化器决定使用不同的连接类型，数据分布会发生变化或呈指数增长。在这种情况下，你只能做出反应。

话说，至少对于 SQL Server 来说，各种“缺失索引”和“最长查询”的 DMV 查询可以在电话前指出问题区域

编辑：澄清...

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

Answer 2

好吧，我会咬一口并采取逆向观点。首先，我会说你永远不应该从做一些你知道会导致你陷入困境的事情开始。如果您想将此称为应用最佳实践，请继续。这就是积极主动应该去的程度。

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

当你发现某些东西没有达到你的设计规范，或者如果某些东西落入你的分析器响应时间列表的最后 10% 或 20%，那么投入你需要的时间来调整它是什么破碎的。

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

Answer 3

您将进行 3 种类型的调整，1 种被动式和 2 种主动式。

反应式

出乎意料的是，一些查询开始给您带来问题。这可能是因为应用程序错误或功能、表增长超出预期、流量高峰或查询优化器变得“有创意”。这可能是半夜的事情，糟糕的网站故障类型，或者它可能是对非关键性质的系统缓慢的响应。无论哪种方式，反应式调优的定义特征是您已经遇到了问题。不用说，您希望尽可能少地做这件事。这让我们...

积极主动的

类型 1：日常维护

根据您的模式更改频率和数据增长速度，每隔几个月或几周，您应该查看数据库性能分析工具的输出（例如 Oracle DBA 的 AWR 报告）。您正在寻找初期问题，即需要 Reactive 调整的问题，以及低悬的结果，不太可能很快引起问题但可以毫不费力地改进以期防止远期问题的项目-未来的问题。你应该花多少时间在这取决于你有多少时间，以及你可以花在什么上，但最佳数量永远不会为零。但是，您可以通过做更多的事情来轻松减少需要花费的金额……

类型 2：适当的设计

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

那么，在 DBA 领域，什么才算是过早的优化呢？在我的列表中最重要的是在没有证明需要的情况下牺牲规范化。当然，您可以在父行上维护一个总和，而不是在运行时从子行计算它，但您真的需要这样做吗？如果您是 Twitter 或 Amazon，那么战略性反规范化和预先计算可能是您最好的朋友。如果您正在为 5 个用户设计一个小型会计数据库，则需要将促进数据完整性的适当结构放在首位。其他过早的优化同样是一个优先事项。不要花费数小时来调整每天运行一次并需要 10 秒的查询，即使您认为可以将其缩短为 0.1 秒。也许你有一份每天运行 6 小时的报告，但在投入时间调整它之前，探索将其作为批处理作业进行调度。如果您的生产负载从未浮动超过 10%（假设您可以管理安全性），请不要投资于单独的实时复制报告实例。

通过针对真实数据进行测试，对增长和流量模式（加上峰值允许）进行有根据的猜测，并应用您对平台优化器怪癖的了解，您可以部署运行（接近）最佳的查询，不仅现在，而且在未来，并且在不太理想的条件下。当您应用适当的技术时，可以准确预测和优化查询性能（每个组件都尽可能快）。

（当你在做的时候，学习统计学！）

Answer 4

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

您的追溯调整计划非常务实。当您进行测试时，您应该记录预期的时间和吞吐量，并且有时应该实际构建分析，让您知道何时生产过程不符合设计规范。通过这种方式，您可以提前确定需要调整哪些代码。然后，您不仅可以确定问题是什么，还可以确定为什么没有在设计/测试阶段发现它。

Answer 5

对我来说，性能测试一直是开发过程的一部分。想要更改此表、更改此报告、添加此功能？作为测试的一部分，您确保可以将个人和整体性能与已知基线和/或需求进行比较（例如，某些报告在后台运行或以其他方式自动化，因此性能 - 或者更确切地说是速度 - 在系统并不总是最优先考虑的）。

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