最近我听到很多人说我应该看看我的 SQL 的执行计划来判断它的执行情况。但是,我不确定从哪里开始使用此功能或它的确切含义。
我正在寻找对执行计划的作用、它的限制是什么以及我如何利用它的一个很好的解释,或者寻找一个可以做的资源。
最近我听到很多人说我应该看看我的 SQL 的执行计划来判断它的执行情况。但是,我不确定从哪里开始使用此功能或它的确切含义。
我正在寻找对执行计划的作用、它的限制是什么以及我如何利用它的一个很好的解释,或者寻找一个可以做的资源。
它描述了服务器用来检索您的数据的实际算法。
像这样的SQL
查询:
SELECT *
FROM mytable1
JOIN mytable2
ON …
GROUP BY
…
ORDER BY
…
, 描述应该做什么,但不描述应该如何做。
执行计划显示如何:使用哪些索引,选择哪些连接方法(嵌套循环或散列连接或合并连接),结果如何分组(使用排序或散列),它们如何排序等。
不幸的是,即使是现代SQL
引擎也无法自动为或多或少复杂的查询找到最佳计划,SQL
开发人员仍然需要重新构造查询以使其具有高性能(即使它们执行原始查询所做的事情)。
一个经典的例子就是这些查询:
SELECT (
SELECT COUNT(*)
FROM mytable mi
WHERE mi.id <= mo.id
)
FROM mytable mo
ORDER BY
id
和
SELECT RANK() OVER (ORDER BY id)
FROM mytable
,它们的作用相同,理论上应该使用相同的算法执行。
然而,没有实际的引擎会优化前一个查询来实现相同的算法,即将一个计数器存储在一个变量中并增加它。
它会做它被告知要做的事情:一遍又一遍地计算行数。
要优化查询,您需要实际了解幕后发生的事情,这就是执行计划向您展示的内容。
您可能想在我的博客中阅读这篇文章:
一种缓解这种情况的方法是,只需在 SQL Management Studio 中对某些查询使用“Ctrl L”(查询|显示估计的执行计划)。
这将导致显示执行计划的图形视图,起初它比文本版本更容易“解码”。
简而言之查询计划:
本质上,查询计划显示了 SQL Server 打算用于解决查询的方式。
确实有很多选择,即使是简单的查询。
例如,在处理 JOIN 时,需要决定是循环遍历“表 A”的 [过滤] 行并查找“表 B”的行,还是先循环遍历“表 B”(这是一个简化的示例,因为还有许多其他技巧可用于处理 JOIN)。通常,SQL 将估计将由任一表生成的 [已过滤] 行的数量,并为外部循环选择计数最小的行(因为这将减少在另一个表中的查找次数)
另一个示例是决定使用(或不使用)哪些索引。
网上资源很多,也有很多书籍对查询计划进行了比较详细的描述,难点在于SQL性能优化是一个非常广泛和复杂的问题,很多这样的资源对于新手来说往往过于详细;在深入了解查询的许多 [重要] 细节之前,首先需要了解 SQL Server 的基本原理和结构(索引的工作方式、数据存储的方式、聚集索引和堆之间的区别……)优化。这有点像棒球:首先您需要了解规则,然后才能理解与游戏策略相关的所有微妙 [和重要] 概念。
有关其他指针,请参阅此相关的SO Question。
这是一个很好的资源,可以帮助您理解它们 http://downloads.red-gate.com/ebooks/HighPerformanceSQL_ebook.zip
这来自 red-gate,这是一家生产出色 SQL 服务器工具的公司,它是免费的,值得花时间下载和阅读。
这是知识的一个非常严肃的部分。我强烈推荐这方面的特殊培训课程。至于我,在花了一周的时间学习课程后,我将查询的性能提高了大约 1000 倍(怀旧)
执行计划向您展示了数据库如何获取、排序和过滤查询所需的数据。
例如:
SELECT
*
FROM
TableA
INNER JOIN
TableB
ON
TableA.Id = TableB.TableAId
WHERE
TableB.TypeId = 2
ORDER BY
TableB.Date ASC
将导致执行计划显示数据库从 TableA 和 TableB 获取记录,匹配它们以满足 JOIN,过滤以满足 WHERE 并排序以满足 ORDER BY。
由此,您可以找出导致查询速度变慢的原因,查看索引是否有益,或者您是否可以通过其他方式加快速度。