修复运行缓慢的SQL查询

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

如果有人抱怨查询运行缓慢，第一步该怎么办

我说我运行

sp_who2

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

有人能给我提供他们对此的反馈吗？这是最好的答案还是有更好的方法

---

谢谢

我真的说不出哪一个是最好的答案，但我会回答：分析答案。这应该是检查性能问题的基础

---

互联网上有大量关于分析执行计划的信息。我建议你去看看。

这是我多年来提出的面试问题之一。请记住，我不使用它作为是/否，我使用它来衡量他们的SQL Server知识有多深，以及他们是以服务器还是以代码为中心

您的答案是如何找到哪个查询运行缓慢，并可能检查服务器资源原因，以了解它为什么突然运行缓慢。根据您的回答，我将开始将您标记为操作DBA类型。这些正是操作DBA在接到服务器突然运行缓慢的呼叫时执行的步骤。如果这就是我面试的目的，而这也是你想要的，那就好了。例如，我可能会进一步深入了解，一旦你发现了僵局，你将采取什么措施来解决这个问题，但我不希望人们能够深入了解。如果不是死锁或阻塞，更好的答案是捕获执行计划并查看是否有过时的统计数据。也有可能正在进行参数嗅探，因此可能需要“重新编译”存储的进程。这些是我看到DBA遇到的典型问题。我不经常为DBA面试，所以其他人可能会有更深层次的问题

但是，如果面试是针对开发人员的工作，那么我希望答案更多的是假设我们已经找到了运行缓慢的查询，并且该查询是可复制的。如果需要的话，我甚至会继续说下去。开发人员可以控制的内容与操作DBA可以控制的内容不同，因此我希望开发人员开始查看代码

人们通常会建议此时查看执行计划，因此建议将其作为一个好的答案。稍后我会解释为什么我不一定同意这是最好的第一步。然而，如果受访者此时确实提到了执行计划，我接下来的问题是询问他们在执行计划中寻找什么。最常见的答案是查找表扫描，而不是查找，可能会显示缺少索引的迹象。这些答案显示了我在执行计划方面的更多经验，它们与寻找整体百分比最高的步骤和/或寻找粗线条有关

我发现在开始执行计划时，很多查询调优工作都走错了方向，解决方案也变得很麻烦，因为调优查询的人不知道他们希望执行计划是什么样子，只是他们不喜欢自己拥有的计划。然后，他们会尝试将注意力集中在看似表现最差的步骤上，添加索引、查询提示等，但结果可能是由于其他步骤的原因，整个执行计划颠倒了，并且他们调整了错误的部分。例如，如果有三个表在外键上连接在一起，而第三个表缺少索引，SQL Server可能会决定下一个最佳计划是以相反的方向遍历这些表，因为主键索引存在于其中。副作用可能是第一张桌子看起来是有问题的，而实际上是第三张桌子

我对查询进行调优的方法，因此我更喜欢听到作为答案的方法，是查看代码，了解代码试图做什么，以及我希望连接如何流动。我开始从第一个表开始，将查询分解为多个部分。请记住，我在这里松散地使用术语“first”来表示我希望SQLServer从中开始的表。这不一定是列出的第一个表。然而，它通常是最小的表，尤其是应用了“where”的表。然后，我将一个接一个地慢慢添加其他表，看看是否可以找到查询转向南方的地方。它通常是一个缺失的索引，没有可搜索性，基数太低，或者陈旧的统计数据。如果你作为被采访者在上下文中使用这些确切的术语，那么无论是谁在采访你，你都会在这个问题上取得好成绩

此外，一旦您对连接的流程有了预期，现在是将您的预期与实际执行计划进行比较的好时机。这就是你如何判断一个计划是否对你不利的方法

---

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

使用SQL Profiler。执行所需的设置并运行存储过程，并检查哪个语句的持续时间更长。单独执行这些语句，获得执行计划。检查缺少的索引、联接顺序（首先联接较小的表）。尝试使用临时表连接表。

我想我是一个基于Bruce面试模型的编码员，但我目前正在处理一个导致我出现这种情况的缓慢查询问题。我们使用nHibernate作为我们的ORM，一些我从未见过的糟糕技术在与nHibernate对话时没有考虑到延迟加载。因此，慢查询是慢的，因为它实际上是一个可怕的查询，加入eve