执行计划顺序不符合一般规则

作者：手机用户2502895461 | 来源：互联网 | 2018-06-12 05:07

? 在Oracle performance tuning guide中，对执行计划顺序的描述是最右最上最先执行，然后父步骤执行，也就是最右边的步骤最先执行，如果同等级，那么最上边的最先执行，然后执行其父步骤（文档原文：The execution order in EXPLAIN PLAN output begins with the line that is the?furthest indented to the right. The next step is the parent of that line. If two lines?are indented equally, then the top line is normally executed first）。

? ? ? 在实际应用中，这个规则不是完全正确的。ORACLE的SQL内部步骤的执行顺序与其计划中的展现，会有一定的差别，如果不仔细分析，而且一味相信文档，那么可能会感觉很迷惑。比如在标量子查询中(scalary subquery)，执行计划的显示会非常让人困惑，如：

SQL> select * from a;
? ? ? ? ID NAME
&＃8212;&＃8212;&＃8212;- &＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;-
? ? ? ? ?1 a
? ? ? ? ?2 b
? ? ? ? ?3 c
3 rows selected.

SQL> select * from b;
? ? ? ? ID NAME
&＃8212;&＃8212;&＃8212;- &＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;-
? ? ? ? ?1 x1
? ? ? ? ?2 x2
2 rows selected.

SQL> SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID)?bid FROM a;

执行计划
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;-
Plan hash value: 2657529235
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8211;
| Id ?| Operation ? ? ? ? | Name | Rows ?| Bytes | Cost (%CPU)| Time ? ? |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8211;
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? 3 | ? ?60 | ? ? 3 ? (0)| 00:00:01 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ? 1 | ? ?13 | ? ? 3 ? (0)| 00:00:01 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? 3 | ? ?60 | ? ? 3 ? (0)| 00:00:01 |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8211;
Predicate Information (identified by operation id):
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
? ?1 &＃8211; filter(&＃8220;B&＃8221;.&＃8221;ID&＃8221;=:B1)

? ? ??如果按照文档的的分析，显然ID=2的与ID=1的是同等级的，ID=1的在ID=2的上面，那么最后执行计划的顺序应该是1&＃8212;->2&＃8212;&＃8211;>0，但是分析下，显然不是这样的顺序，肯定是必须获得a.id之后，才能用a.id去查找B。通过谓词中的&＃8221;B&＃8221;.&＃8221;ID&＃8221;=:B1可以看出来，:B1,类似于绑定变量，这里就2张表，而且根据SQL查询，肯定来源于A.ID。所以对于标量子查询的计划，应该是2&＃8212;->1&＃8212;&＃8211;>0，而且2与1的操作是类似于NESTED LOOPS(与其不同的是，标量子查询的驱动表是inner table)的操作，每1个A的行，都会执行一次B，当然，ORACLE内部肯定是有优化的，这种优化就是会缓存已经匹配的A.ID值，遇到相同的，不会重复扫描B。可以通过DBMS_XPLAN.DISPLAY_CURSOR详细看看如何执行的：

SQL> @display_cursor
SQL_ID ?caq6tcx266xnq, child number 1
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;-
SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID) bid FROM a

Plan hash value: 2657529235
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
| Id ?| Operation ? ? ? ? | Name | Starts | E-Rows | A-Rows | ? A-Time ? | Buffers |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? ?1 | ? ? ? ?| ? ? ?3 |00:00:00.01 | ? ? ? 8 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ???3?| ? ? ?1 | ? ? ?2 |00:00:00.01 | ? ? ?21 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? ?1 | ? ? ?3 | ? ???3?|00:00:00.01 | ? ? ? 8 |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;

Predicate Information (identified by operation id):
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
? ?1 &＃8211; filter(&＃8220;B&＃8221;.&＃8221;ID&＃8221;=:B1)

? ? ??其中A共3行，访问B 3次，返回B 2行，因为有一行不匹配，由A的行驱动访问B。因为这里A.ID无重复值，下面插入一行id=1的，因为id=1已经在A表中存在，因此，标量子查询有缓存，所以对B的扫描还是3次，而不是4次，如下：

SQL> INSERT INTO a VALUES(1,&＃8217;d');
1 row created.

SQL> COMMIT;
Commit complete.

SQL>??@display_cursor
SQL_ID ?caq6tcx266xnq, child number 0
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;-
SELECT a.ID,a.NAME,(SELECT b.ID FROM b WHERE a.ID=b.ID) bid FROM a

Plan hash value: 2657529235

&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
| Id ?| Operation ? ? ? ? | Name | Starts | E-Rows | A-Rows | ? A-Time ? | Buffers |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;
| ? 0 | SELECT STATEMENT ?| ? ? ?| ? ? ?1 | ? ? ? ?| ? ? ?4 |00:00:00.01 | ? ? ? 8 |
|* ?1 | ?TABLE ACCESS FULL| B ? ?| ? ???3?| ? ? ?1 | ? ? ?2?|00:00:00.01 | ? ? ?21 |
| ? 2 | ?TABLE ACCESS FULL| A ? ?| ? ? ?1 | ? ? ?4 | ? ???4?|00:00:00.01 | ? ? ? 8 |
&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;&＃8212;

? ?1 &＃8211; filter(&＃8220;B&＃8221;.&＃8221;ID&＃8221;=:B1)

? ? ?从计划中可以看到，虽然A是4行，但是因为DISTINCT A.ID是3行，所以还是扫描B 3次，其中ID=1的访问一次即缓存结果，通过A-ROWS可以看到B还是返回2行，而不是3行。所以不要看到标量子查询就认为效率不行，标量子查询和FILTER类似，如果能够对标量子查询走索引扫描，甚至UNIQUE INDEX SCAN，如果主表查询的行重复值特别多，效率还是很高的，标量子查询在一定程度上，消除了JOIN，经常在查询这种对应某表的行，需要匹配另一表的某个列值，比JOIN效率高（当然，既然类似于NESTED LOOPS了，结果集肯定不会很大，不然效率会差，这个tom的高效设计上有详细的讲解）。
? ?
? ? 本文主要就是讲解下，执行计划反应了SQL的执行顺序，但是如果通过执行计划准确知道SQL中的执行顺序，并不是只要了解文档中说的规则就可以了，在实际应用中，可能会碰到这样那样的问题，文档当然很少有错误，但是文档大多说的都是普遍的规则，SO，在学习过程中，对不理解的问题，要随时质疑，并论证之。

原文地址：执行计划顺序不符合一般规则, 感谢原作者分享。

sql
scala

推荐阅读

join
SQL查询分组后每组行数的统计方法

本文介绍了在SQL中查询分组后每组行数的统计方法。通过使用count()函数和GROUP BY子句可以统计每组的行数，但是如何统计所有组的行数呢？本文提供了一种实现方法，并给出了相应的SQL查询语句。 ... [详细]

蜡笔小新 2023-12-14 19:37:41
input
程度|也就是_论文精读：Neural Architecture Search without Training

篇首语：本文由编程笔记#小编为大家整理，主要介绍了论文精读：NeuralArchitectureSearchwithoutTraining相关的知识，希望对你有一定的参考价值。 ... [详细]

蜡笔小新 2023-10-16 16:33:20
input
北美最大的免费流媒体播放平台 Tubi 继续招聘！

[我们是谁？] ... [详细]

蜡笔小新 2023-10-16 12:48:49
io
spark任务已经执行结束，但还显示RUNNING状态

spark的任务已经执行完成：scalavallinesc.textFile(hdfs:vm122:9000dblp.rdf)line:org.apache ... [详细]

蜡笔小新 2023-10-16 12:18:00
client
基于 Docker 快速部署多需求 Spark 自动化测试环境

基于,docker,快速,部署,多,需求,spark ... [详细]

蜡笔小新 2023-10-16 11:58:06
client
python开方运算符_OpenCVPython常用图像运算：加减乘除幂开方对数及位运算

☞░前往老猿Python博客https:blog.csdn.netLaoYuanPython░一、引言在写该文之前，老猿就图像的一些运算已经单独边学边发了࿰ ... [详细]

蜡笔小新 2023-10-16 11:43:28
io
kafka 0.9+消费者配置参数说明

ConsumerConfiguration在kafka0.9使用JavaConsumer替代了老版本的scalaConsumer。新版的配置如下：bootstrap. ... [详细]

蜡笔小新 2023-10-16 10:44:59
io
php 垃圾回收默认打开,PHP垃圾回收机制详解

PHP的基本GC概念PHP语言同其他语言一样，具有垃圾回收机制。那么今天我们要为大家讲解的内容就是关于PHP垃圾回收机制的相关问题。希望对大家有所帮助。PHPstrt ... [详细]

蜡笔小新 2023-10-16 09:08:15
case
scala中的部分应用函数和偏函数的区别

经常把部分应用函数（PartialAppliedFunction)和偏函数（PartialFunction）搞混。本人总结如下：部分应用函数（PartialAppliedF ... [详细]

蜡笔小新 2023-10-15 20:12:20
input
Binding of lowercase GraphQL type name to Go struct

Whathappened?WehavesomeexistingGraphQLschemathatuseslowercasedna ... [详细]

蜡笔小新 2023-10-15 13:26:31
io
dataguard日志传输模式解析_SOFAJRaft 日志复制pipeline 实现剖析 | SOFAJRaft 实现原理

SOFAStack（ScalableOpenFinancialArchitectureStack）是蚂蚁金服自主研发的金融级分布式架构，包 ... [详细]

蜡笔小新 2023-10-15 08:16:39
io
rust编程_在Rust中编程：好，坏，丑。

rust编程这篇文章是关于我通过解决Twitch上尚未解决的所有CtCI问题来学习Rust的经验。英国科学博物馆集团AdaLovelace的肖像Rust徽标，由Moz ... [详细]

蜡笔小新 2023-10-14 20:06:42
io
透明木头问世！“木头大王”胡良兵再发顶刊，已成立公司加速落地69

道翰天琼认知智能机器人平台API接口大脑为您揭秘。木材是人类最古老的建筑材料之一，也是一种绿色节能材料，我们对其外观的认知可谓根深蒂固。如今，随着透明木材的问世，这一观感将被颠覆。 ... [详细]

蜡笔小新 2023-10-14 19:54:28
io
XEON® Scalable如何为虚拟化挑选合适的CPU

Intel于去年7月发布了XEON的新一代CPU:XEON®processorScalablefamily(以下简称为Skylake-SP),现在已经在项目中，看到了新的Skyla ... [详细]

蜡笔小新 2023-10-14 18:45:40
input
rxjs 源码分析1-(fromEvent)

我们先从我们最常用的事件处理开始，Rxjs对事件的处理有一个其实现的效果如下图： ... [详细]

蜡笔小新 2023-10-14 18:19:37

手机用户2502895461

这个家伙很懒，什么也没留下！

Tags | 热门标签

RankList | 热门文章