提高 SQL Server 查询性能： 第 1 部分

引言

最近，我一直在回答许多关于优化 SQL Server 查询和检查开发人员是否充分利用数据库功能的问题。因此，我决定整理一系列关于如何最大化利用数据库开发的文章。

在本文中，我们将探讨如何识别运行缓慢的查询以及可以采取哪些措施来改进它们。

在下一篇文章中，我们将更深入地研究执行计划和索引，以及如何进一步利用我们在此识别出的内容。

开始之前

在进行任何代码或存储过程之前，我们需要思考我们想要实现的目标。我们已经说过要识别运行缓慢的查询，但我们所说的运行缓慢是指什么？这高度主观，并且实际上取决于数据库的用途和操作的复杂性。数据仓库的运行时间阈值显然会比直观的 OLTP 系统高得多。出于本文的目的，我将假设我们将运行缓慢的查询定义为运行时间超过 3 秒的查询。

现在我们已经确定了要查找的标准，我们如何找出哪些查询实际上需要这么长时间？这就是我们新的好朋友 SQL Profiler (SQL Server 剖析器) 发挥作用的地方。此工具在识别安全问题、瓶颈、查询占用过多资源的情况等方面可能非常有价值。

注意：在我们的示例中，我将使用 SQL Server 2000 Profiler。

我们在分析数据库时需要牢记一些事项

• 仅选择需要收集的数据。收集的数据越多，消耗的资源就越多，这会降低性能。我们只选择绝对需要的事件和列。
• 分析器应运行在与我们正在监视的计算机不同的计算机上，因为我们不希望影响数据库服务器的性能。
• 我们希望在典型时期内收集数据。如果在周六早上分析我们的应用程序，而我们的在线时间通常是周一至周五的上午 9 点至下午 5 点，那么分析是毫无意义的。
• 随着时间的推移，我们可能需要重新定义运行缓慢查询的标准。
• 有时试图提高查询性能是徒劳的，或者是不可能的。
• 过滤信息有助于减少无关信息。

入门

那么，我们如何设置 SQL Profiler 来捕获我们需要的信息呢？嗯，一旦我们启动它，就需要设置一个跟踪。为此，选择 **文件 > 新建 > 跟踪**。这将提示我们选择要用于连接数据库的数据库和凭据。请注意，我们必须以 sysadmin 服务器角色的成员身份连接。

连接到数据库后，我们将看到“跟踪属性”对话框。我们将在其中选择要使用的事件、列和过滤器。

快速提示：使用 **文件 > 新建 > 跟踪模板**，我们可以设置一个可以反复使用的模板。在本文中，有些内容可以被提取并保存到模板中以供重复使用。

在 **事件** 选项卡下，我们将选择以下事件

• 存储过程 > RPC:Completed
• TSQL > SQL:BatchCompleted

这两个事件告诉我们哪些过程和直接查询需要关注。

在 **数据列** 选项卡中，我们将只捕获以下列

在 **组** 节点下

• 持续时间

在 **列** 节点下

• EventClass (事件类别)
• DatabaseName
• TextData (文本数据)
• CPU
• 读取
• 写入
• NTUserName
• LoginName
• SPID

我发现 **NTUserName** 和 **LoginName** 标识符有助于识别执行临时查询的用户，这样我们在稍后分析数据时就可以忽略它们。

现在我们将设置过滤器。为此，在 **过滤器** 选项卡下，设置以下内容

• 持续时间 > 大于或等于 > 3000（3 秒）
• 勾选 **排除系统 ID** 复选框

稍后，我们可能会考虑添加其他过滤器（例如限制我们正在分析的登录名），但目前，这已足够。

在 **常规** 选项卡中，我们可以选择是否将数据保存到文件或 SQL Server 数据库。为了我们的目的，我们将选择一个文件，并且不限制其增长。

当我们点击 **运行** 时，分析器将开始跟踪我们要监视的一个或多个数据库。我们将让分析器运行一段时间，以便获得大量可供查看的信息。

分析数据

假设我们有运行缓慢的查询，现在我们想知道它们是什么。此时，跟踪中重复出现相同的查询是很常见的，所以我们可以大大减少我们需要查看的查询数量。

同样，我们不应该急于修复问题。我们需要停下来考虑这些查询在做什么。例如，如果一个查询运行了 10 秒，但每六个月才运行一次，那么尝试优化它就没有多大意义。如果一个查询运行了 10 秒，但每分钟运行两次，那么它就是一个很可能需要改进的候选。

Profiler 的好消息是，它会在跟踪窗口中显示运行的查询，因此我们可以将这些数据复制到 **查询分析器** 中并查看执行计划。有了执行计划和 **索引优化顾问** 等工具，我们就有可能改进查询。

在下一篇文章中，我们将更深入地研究执行计划和索引，以及如何进一步利用我们在此识别出的内容。