sql - 修复运行缓慢的SQL查询

Question

在许多采访中我都被问到了这一点:

What is the first step to do if somebody complains that a query is running slowly?

我说我运行 sp_who2 <active>并检查正在运行的查询，以查看哪个占用了最多的资源，以及是否存在任何锁定，阻塞或死锁。

有人可以向我提供有关此问题的反馈吗？这是最佳答案还是有更好的方法？

谢谢!

Answer 1

这是我多年来提出的面试问题之一。请记住，我不将其用作是/否，而是使用它来评估他们对SQL Server的了解有多深，以及他们是服务器还是代码集中的。

您的答案指向如何查找运行缓慢的查询，并可能检查服务器资源突然运行缓慢的原因。根据您的回答，我将开始将您标记为可操作的DBA类型。这些正是操作中的DBA接到服务器突然运行缓慢的调用时所执行的步骤。如果那是我正在面试的内容，那就是您要找的东西，那很好。例如，一旦发现僵局，我可能会进一步探讨解决该问题的步骤，但是我不希望人们能够做得更深入。如果不是死锁或阻塞，那么更好的答案是捕获执行计划，看看是否有陈旧的统计信息。还可能进行参数嗅探，因此可能需要“重新编译”存储的proc。这些是我看到DBA遇到的典型问题。我不常去DBA面试，所以也许其他人在这里有更深层次的问题。

但是，如果面试是针对开发人员的工作，那么我希望得到的答案更多是假设我们已经确定了哪个查询运行缓慢，并且该查询是可重复的。我什至会继续声明，并在需要时进行说明。开发人员可以控制的事情与运营DBA可以控制的事情不同，因此我希望开发人员可以开始查看代码。

人们通常会建议此时考虑执行计划，因此建议将其作为一个很好的答案。我稍后再解释为什么我不一定同意这是最好的第一步。但是，如果受访者此时确实提到了执行计划，那么我的后续问题将是询问他们对执行计划的要求。最常见的答案是查找表扫描而不是查找，可能会显示缺少索引的迹象。答案向我展示了更多的执行计划工作经验，这与寻找占整体百分比最高的步骤和/或寻找粗线有关。

我发现许多查询调优工作在执行计划开始时就误入歧途，解决方案变得笨拙，因为调优查询的人不知道他们想要执行计划的样子，只是他们不喜欢他们的执行计划。有。然后，他们将尝试着眼于看似效果最差的步骤，添加索引，查询提示等，结果可能会发现由于其他步骤，整个执行计划被颠倒了，并且他们正在调整错误的位置片。例如，如果您在外键上将三个表连接在一起，而第三个表缺少索引，则SQL Server可能会决定下一个最佳计划是沿相反的方向移动表，因为那里存在主键索引。副作用可能是它看起来像第一个表确实是第三个表时出现问题的表。

我调优查询的方式(因此我更希望听到作为答案的方式)是查看代码，并对代码尝试执行的操作以及我期望联接如何流动有一种感觉。我从第一个表开始将查询分为几部分。请记住，我在这里宽松地使用了“第一”一词，以表示我希望SQL Server在其中开始的表。这不一定是列出的第一个表。但是，它通常是最小的表，尤其是应用了“where”的表。然后，我将一个接一个地慢慢添加其他表，以查看是否可以找到查询向南的位置。它通常是缺少索引，没有可持久性，基数太低或统计信息过时。如果您作为受访者在上下文中使用这些确切术语，那么无论谁在采访您，您都将面对这个问题。

另外，一旦对联接的运行方式有了期望，现在就可以将期望与实际执行计划进行比较。这是您如何确定计划是否生效的方法。

如果我要回答问题或调整实际查询，我还要补充一点，我想获得表上的行数，并查看联接和“where”子句中所有列的选择性。我还喜欢实际查看数据。有时问题从代码中并不会很明显，但是当您看到一些数据时，问题就会变得明显。