sql - 你如何解释查询的解释计划？

Question

当试图了解 SQL 语句是如何执行的时，有时建议查看解释计划。在解释（理解）解释计划时应该经历什么过程？什么应该突出，“哦，这工作很棒？” 与“哦，不，那不对。”

score 81 · Accepted Answer

每当我看到关于全表扫描不好而索引访问好的评论时，我都会不寒而栗。全表扫描、索引范围扫描、快速全索引扫描、嵌套循环、合并连接、哈希连接等都是分析人员必须理解的简单访问机制，并结合数据库结构和查询目的的知识为了得出任何有意义的结论。

完全扫描只是读取数据段（表或表（子）分区）的大部分块的最有效方式，虽然它通常可以指示性能问题，但仅在上下文中是否是实现查询目标的有效机制。作为一名数据仓库和 BI 人员，我对性能的第一个警告标志是基于索引的访问方法和嵌套循环。

因此，对于如何阅读解释计划的机制，Oracle 文档是一个很好的指南：http: //download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

还请仔细阅读《性能调优指南》。

还有一个“基数反馈”的谷歌，一种技术，其中解释计划可用于将查询中各个阶段的基数估计与执行期间经历的实际基数进行比较。我相信 Wolfgang Breitling 是该方法的作者。

所以，底线：了解访问机制。了解数据库。了解查询的意图。避免经验法则。

score 13 · Accepted Answer

这个话题太大了，无法在这样的问题中回答。您应该花一些时间阅读Oracle 的性能调优指南

score 5 · Accepted Answer

下面的两个示例显示了使用 INDEX 的 FULL 扫描和 FAST 扫描。

最好专注于您的成本和基数。查看示例，索引的使用降低了运行查询的成本。

它有点复杂（我没有 100% 的处理）但基本上成本是 CPU 和 IO 成本的函数，基数是 Oracle 期望解析的行数。减少这两者是一件好事。

不要忘记查询的成本会受到您的查询和 Oracle 优化器模型（例如：COST、CHOOSE 等）以及您运行统计信息的频率的影响。

示例 1：

扫描 http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

使用索引的示例 2：

索引 http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

正如已经建议的那样，请注意 TABLE SCAN。您通常可以避免这些。

score 4 · Accepted Answer

寻找诸如顺序扫描之类的东西可能会有些用处，但现实存在于数字中……除非数字只是估计值！通常比查看查询计划更有用的是查看实际执行情况。在 Postgres 中，这就是 EXPLAIN 和 EXPLAIN ANALYZE 之间的区别。EXPLAIN ANALYZE 实际执行查询，并获取每个节点的真实时间信息。这让您可以看到实际发生的事情，而不是计划者认为会发生的事情。很多时候，您会发现顺序扫描根本不是问题，而是查询中的其他内容。

另一个关键是确定实际昂贵的步骤是什么。许多图形工具将使用不同大小的箭头来指示计划中不同部分的成本。在这种情况下，只需寻找有细箭头进入和粗箭头离开的步骤。如果您不使用 GUI，则需要观察数字并寻找它们突然变大的地方。稍加练习，就可以很容易地找出问题区域。

score 3 · Accepted Answer

对于这些问题，最好的办法是ASKTOM。特别是他对该问题的回答包含指向在线 Oracle 文档的链接，其中解释了许多此类规则。

要记住的一件事是，解释计划确实是最好的猜测。

学习使用 sqlplus 并尝试使用 AUTOTRACE 命令将是一个好主意。有了一些硬数字，您通常可以做出更好的决定。

但你应该问。他什么都知道：）

score 2 · Accepted Answer

解释的输出告诉您每个步骤花费了多长时间。首先是找到花费了很长时间的步骤并理解它们的含义。诸如顺序扫描之类的事情会告诉您您需要更好的索引 - 这主要是研究您的特定数据库和经验的问题。

score 2 · Accepted Answer

一个“哦，不，那不对”通常是表扫描的形式。表扫描不使用任何特殊索引，并且有助于清除内存缓存中的所有有用信息。例如，在 postgreSQL 中，你会发现它看起来像这样。

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

有时，表扫描比使用索引查询行更理想。但是，这是您似乎正在寻找的危险信号模式之一。

score 2 · Accepted Answer

基本上，您会查看每个操作，并根据您对操作应该如何工作的了解，看看这些操作是否“有意义”。

例如，如果您在各自的列 C 和 D (AC=BD) 上连接两个表 A 和 B，并且您的计划在表上显示聚集索引扫描（SQL Server 术语 - 不确定 oracle 术语） A，然后嵌套循环连接到表 B 上的一系列聚集索引搜索，您可能会认为有问题。在这种情况下，您可能希望引擎执行一对索引扫描（在连接列上的索引上），然后进行合并连接。进一步的调查可能会揭示错误的统计信息，从而使优化器选择该连接模式或实际不存在的索引。

score 1 · Accepted Answer

查看计划的每个子部分花费的时间百分比，并考虑引擎在做什么。例如，如果它正在扫描一个表，请考虑在正在扫描的字段上放置一个索引

score 1 · Accepted Answer

我主要寻找索引或表扫描。这通常告诉我我在 where 语句或 join 语句中的重要列上缺少索引。

来自http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx：

如果您在执行计划中看到以下任何内容，则应将其视为警告信号并调查它们是否存在潜在的性能问题。从性能的角度来看，它们中的每一个都不太理想。
* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 
并非总是可以避免这些，但是您可以避免的越多，查询性能就会越快。

score -7 · Accepted Answer

经验法则

（您可能也想阅读详细信息：

坏的

几个大表的表扫描

好的

使用唯一索引
索引包含所有必填字段

最常见的胜利

在我见过的大约 90% 的性能问题中，最简单的方法是将包含大量（4 个或更多）表的查询分解为 2 个较小的查询和一个临时表。

sql - 你如何解释查询的解释计划？

11 回答 11

经验法则

坏的

好的

最常见的胜利

Related

Reference