第一章(2)——预估和实际执行计划

原文:第一章(2)——预估和实际执行计划

正如前面提到的,有两种不同类型的执行计划,第一种,就是优化器的输出结果,成为预估执行计划,里面的操作符或者步骤都是逻辑步骤,因为他们代表着执行计划在优化器中的视图,但是并不表现在实际执行中物理层面的发生。

另外一种计划是表示查询实际执行的输出结果。这种类型叫做实际执行计划,表示查询在实际执行时发生的事情。

这两个计划显示独立的不同的结果集,但是可以看出有巨大的相同之处。大部分情况下,相同的开销的相同的操作符会出现在两种执行计划中。但是当发生重编译,SQLServer会删除计划缓存中的计划并重建它,此时两者就会有明显的差异。这种情况通常发生于统计信息的更改,或存储引擎在处理查询时发生的其他事情。我们将在这章的后面部分更详细地说明。

预估执行计划(后面简称预估计划)是存放在计划缓存中的计划,所以我们对于实际执行计划,只能通过捕捉查询运行的时候产生的执行计划。预估计划从不直接访问数据,但是它对大型的、复杂的、可能运行很久的查询分析相当有效。但是实际计划是首选的,因为它能显示很多运行过程中重要的统计信息如特定操作符实际访问的行数。通常情况下,这种额外的信息使得实际计划成为你最常用的方式,但是预估计划机器重要,特别是因为你可以从计划缓存中获取。

时间: 2024-10-02 04:21:40

第一章(2)——预估和实际执行计划的相关文章

《高度安全环境下的高级渗透测试》—第1章1.3节制订执行计划

1.3 制订执行计划一旦开始测试,你需要准备一些东西.这需要一个执行计划,你的所有设备和脚本都需要启动并处于运行状态,你还需要制定一些机制来记录所有的步骤和操作.这样也能为你自己和团队其他成员提供一个参考.你可能现在还记得绕过某台防火墙的步骤,但是当你在4个月之后面对同样的防火墙时,你还记得住么?做好记录对一次成功的渗透测试而言至关重要. 对于本书而言,我们将使用VirtualBox来回顾BackTrack套件的安装过程.VirtualBox是在GNU通用公共许可协议(GPL)保护下,由Orac

一个执行计划异常变更的案例 - 外传之SQL Profile(上)

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> <一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法> <一个执

【云和恩墨大讲堂】从执行计划洞察ORACLE优化器的“小聪明”

作者简介黄浩  惠普 十年一剑,十年磨砺.3年通信行业,写就近3万条SQL:5年制造行业,遨游在ETL的浪潮:2年性能优化,厚积薄发自成一家 主题介绍: Oracle执行计划的另类解读:调皮的执行计划 | 诚实的执行计划 | 朴实的执行计划 说到执行计划,oracle的拥趸们自然而然会兴奋起来.在ORACLE的世界里,执行计划有着其特殊的地位,如果我们将SQL性能优化看成一个生物,那某种程度上,执行计划就是DNA.在某搜索网站中,"oracle 执行计划"关键字的搜索结果与"

第一章(3)——执行计划重用

原文:第一章(3)--执行计划重用 对于服务器来说,所有查询处理都产生出执行计划是非常昂贵的开销,即使SQLServer可以在数毫秒内完成,所以SQLServer会在任何时候尽可能保留并重用计划以便全面降低开销.当执行计划被产生出来后,会存放在一个叫做计划缓存的内存块中. 当我们提交一个查询到服务器时,algebrizer过程就会创建一个hash,类似于一个对于查询的编码签名.这个hash是唯一的,昵称为查询指纹(query fingerprint).每个查询都有一个标识,包括所有包含在查询中的

第六章——根据执行计划优化性能(1)——理解哈希、合并、嵌套循环连接策略

原文:第六章--根据执行计划优化性能(1)--理解哈希.合并.嵌套循环连接策略 前言: 本系列文章包括: 1. 理解Hash.Merge.Nested Loop关联策略. 2. 在执行计划中发现并解决表/索引扫描. 3. 介绍并在执行计划中发现键查找并解决它们.   对于性能优化,需要集中处理以下的问题: 1. 为你的环境创建性能基线. 2. 监控现在的性能并发现瓶颈. 3. 解决瓶颈以便得到更好的性能.   一个预估执行计划是描述查询将会如何执行的一个蓝图,而一个实际执行计划就是一个查询执行时

第六章——根据执行计划优化性能(2)——查找表/索引扫描

原文:第六章--根据执行计划优化性能(2)--查找表/索引扫描 前言:       在绝大部分情况下,特别是从一个大表中返回少量数据时,表扫描或者索引扫描并不是一种高效的方式.这些必须找出来并解决它们从而提高性能,因为扫描将遍历每一行,查找符合条件的数据,然后返回结果.这种处理是相当耗时耗资源的.在性能优化过程中,一般集中于: 1.  CPU 2.  Network 3.  磁盘IO 而扫描操作会增加这三种资源的开销.   准备工作: 下面将创建两个表来查看不同的物理关联操作的不同影响.创建脚本

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一第一篇 执行计划

第一篇 执行计划 执行计划是指示Oracle如何获取和过滤数据.产生最终结果集,是影响SQL语句执行性能的关键因素.我们在深入了解执行计划之前,首先需要知道执行计划是在什么时候产生的,以及如何让SQL引擎为语句生成执行计划. 在深入了解执行计划之前,我们先了解SQL语句的处理执行过程.当一条语句提交到Oracle后,SQL引擎会分为三个步骤对其处理和执行:解析(Parse).执行(Execute)和获取(Fetch),分别由SQL引擎的不同组件完成.SQL引擎的组件如图1-1所示. 1. SQL

第六章——根据执行计划优化性能(3)——键值查找

原文:第六章--根据执行计划优化性能(3)--键值查找 前言:         本文为本系列最后一篇,介绍键值查找的相关知识.         键值查找是具有聚集索引的表上的一个书签查找,键值查找用于SQLServer查询一些非键值列的数据.使用非聚集索引的查询不会有键值查找,但是所有键值查找会伴随非聚集索引出现.这里特别提醒的是键值查找总是伴有嵌套循环关联.   准备工作:   下面将创建一个表,通过执行计划看看键值查找的不同效果.为了产生键值查找,需要两件事情: 1.  聚集索引 2.  非

ORACLE实际执行计划与预估执行计划不一致性能优化案例

  在一台ORACLE服务器上做巡检时,使用下面SQL找出DISK_READ最高的TOP SQL分析时,分析过程中,有一条SQL语句的一些反常现象,让人觉得很奇怪:   SELECT SQL_ID,        SQL_TEXT,        DISK_READS,        BUFFER_GETS,        PARSING_SCHEMA_NAME,        EXECUTIONS FROM   V$SQLAREA ORDER  BY DISK_READS DESC;   在S