【发布时间】:2010-01-29 15:19:05
【问题描述】:
我最近听到很多人说我应该看看我的 SQL 的执行计划,以判断它的执行情况。但是,我不确定从哪里开始使用此功能或它的确切含义。
我正在寻找关于执行计划的作用、其限制是什么以及如何利用它的一个很好的解释,或者寻找可以执行计划的资源。
【问题讨论】:
标签: sql-server tsql sql-execution-plan
我最近听到很多人说我应该看看我的 SQL 的执行计划,以判断它的执行情况。但是,我不确定从哪里开始使用此功能或它的确切含义。
我正在寻找关于执行计划的作用、其限制是什么以及如何利用它的一个很好的解释,或者寻找可以执行计划的资源。
【问题讨论】:
标签: sql-server tsql sql-execution-plan
它描述了服务器用来检索您的数据的实际算法。
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
,它们的作用相同,理论上应该使用相同的算法来执行。
但是,没有实际的引擎会优化前一个查询来实现相同的算法,即。 e.将计数器存储在变量中并递增。
它会做它被告知要做的事情:一遍又一遍地计算行数。
要优化查询,您需要真正了解幕后发生的事情,这就是执行计划向您展示的内容。
您可能想在我的博客中阅读这篇文章:
【讨论】:
【讨论】:
缓解这种情况的一种方法是,只需在 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。
据此,您可以找出导致查询速度变慢的原因,检查索引是否有益,或者是否可以通过其他方式加快速度。
【讨论】: