精华内容
下载资源
问答
  • Oracle执行计划

    千次阅读 2018-07-08 09:51:29
    执行计划是一条查询语句在Oracle中的执行过程或访问路径的描述 二:怎样查看Oracle执行计划?因为我一直用的PLSQL远程连接的公司数据库,所以这里以PLSQL为例:①:配置执行计划需要显示的项:工具 —> 首...

    一:什么是Oracle执行计划?

    执行计划是一条查询语句在Oracle中的执行过程或访问路径的描述

     

    二:怎样查看Oracle执行计划?

    因为我一直用的PLSQL远程连接的公司数据库,所以这里以PLSQL为例:

    ①:配置执行计划需要显示的项:

    工具  —>  首选项 —>   窗口类型  —>  计划窗口  —>  根据需要配置要显示在执行计划中的列

    执行计划配置

    执行计划的常用列字段解释:

    基数(Rows):Oracle估计的当前操作的返回结果集行数

    字节(Bytes):执行该步骤后返回的字节数

    耗费(COST)、CPU耗费:Oracle估计的该步骤的执行成本,用于说明SQL执行的代价,理论上越小越好(该值可能与实际有出入)

    时间(Time):Oracle估计的当前操作所需的时间

    ②:打开执行计划:

    在SQL窗口执行完一条select语句后按 F5 即可查看刚刚执行的这条查询语句的执行计划

    执行计划查看

     

    注:在PLSQL中使用SQL命令查看执行计划的话,某些SQL*PLUS命令PLSQL无法支持,比如SET AUTOTRACE ON

    执行计划sql查看

     

     

     

    三:看懂Oracle执行计划

    看懂执行计划

    ①:执行顺序:

    根据Operation缩进来判断,缩进最多的最先执行;(缩进相同时,最上面的最先执行)

    例:上图中 INDEX RANGE SCAN 和 INDEX UNIQUE SCAN 两个动作缩进最多,最上面的 INDEX RANGE SCAN 先执行;

    同一级如果某个动作没有子ID就最先执行

    同一级的动作执行时遵循最上最右先执行的原则

    例:上图中 TABLE ACCESS BY GLOBAL INDEX ROWID 和 TABLE ACCESS BY INDEX ROWID 两个动作缩进都在同一级,则位于上面的 TABLE ACCESS BY GLOBAL INDEX ROWID 这个动作先执行;这个动作又包含一个子动作 INDEX RANGE SCAN,则位于右边的子动作 INDEX RANGE SCAN 先执行;

    图示中的SQL执行顺序即为:

    INDEX RANGE SCAN  —>  TABLE ACCESS BY GLOBAL INDEX ROWID  —>  INDEX UNIQUE SCAN  —>  TABLE ACCESS BY INDEX ROWID  —>  NESTED LOOPS OUTER  —>  SORT GROUP BY  —>  SELECT STATEMENT, GOAL = ALL_ROWS

    ( 注:PLSQL提供了查看执行顺序的功能按钮(上图中的红框部分) )

     

    ②:对图中动作的一些说明:

    1. 上图中 TABLE ACCESS BY …  即描述的是该动作执行时表访问(或者说Oracle访问数据)的方式;

    表访问的几种方式:(非全部)

    • TABLE ACCESS FULL(全表扫描)
    • TABLE ACCESS BY ROWID(通过ROWID的表存取)
    • TABLE ACCESS BY INDEX SCAN(索引扫描)

    (1) TABLE ACCESS FULL(全表扫描)

    Oracle会读取表中所有的行,并检查每一行是否满足SQL语句中的 Where 限制条件;

    全表扫描时可以使用多块读(即一次I/O读取多块数据块)操作,提升吞吐量;

    使用建议:数据量太大的表不建议使用全表扫描,除非本身需要取出的数据较多,占到表数据总量的 5% ~ 10% 或以上

    (2) TABLE ACCESS BY ROWID(通过ROWID的表存取) :

    先说一下什么是ROWID?

    rowid

    ROWID是由Oracle自动加在表中每行最后的一列伪列,既然是伪列,就说明表中并不会物理存储ROWID的值;

    你可以像使用其它列一样使用它,只是不能对该列的值进行增、删、改操作;

    一旦一行数据插入后,则其对应的ROWID在该行的生命周期内是唯一的,即使发生行迁移,该行的ROWID值也不变。

    让我们再回到 TABLE ACCESS BY ROWID 来:

    行的ROWID指出了该行所在的数据文件、数据块以及行在该块中的位置,所以通过ROWID可以快速定位到目标数据上,这也是Oracle中存取单行数据最快的方法;

    (3) TABLE ACCESS BY INDEX SCAN(索引扫描)

    在索引块中,既存储每个索引的键值,也存储具有该键值的行的ROWID。

    一个数字列上建索引后该索引可能的概念结构如下图:

    index

    所以索引扫描其实分为两步:

    Ⅰ:扫描索引得到对应的ROWID

    Ⅱ:通过ROWID定位到具体的行读取数据

    ----------------索引扫描延伸-------------------

    索引扫描又分五种:

    • INDEX UNIQUE SCAN(索引唯一扫描)
    • INDEX RANGE SCAN(索引范围扫描)
    • INDEX FULL SCAN(索引全扫描)
    • INDEX FAST FULL SCAN(索引快速扫描)
    • INDEX SKIP SCAN(索引跳跃扫描)

    a) INDEX UNIQUE SCAN(索引唯一扫描)

    针对唯一性索引(UNIQUE INDEX)的扫描,每次至多只返回一条记录;

    表中某字段存在 UNIQUE、PRIMARY KEY 约束时,Oracle常实现唯一性扫描;

    b) INDEX RANGE SCAN(索引范围扫描)

    使用一个索引存取多行数据;

    发生索引范围扫描的三种情况:

    • 在唯一索引列上使用了范围操作符(如:>   <   <>   >=   <=   between)
    • 在组合索引上,只使用部分列进行查询(查询时必须包含前导列,否则会走全表扫描)
    • 对非唯一索引列上进行的任何查询

    c) INDEX FULL SCAN(索引全扫描)

    进行全索引扫描时,查询出的数据都必须从索引中可以直接得到(注意全索引扫描只有在CBO模式下才有效)

    ----------------------- 延伸阅读:Oracle优化器简述 -----------------------

    Oracle中的优化器是SQL分析和执行的优化工具,它负责生成、制定SQL的执行计划。

    Oracle的优化器有两种:

    • RBO(Rule-Based Optimization) 基于规则的优化器
    • CBO(Cost-Based Optimization) 基于代价的优化器

    RBO:

    RBO有严格的使用规则,只要按照这套规则去写SQL语句,无论数据表中的内容怎样,也不会影响到你的执行计划;

    换句话说,RBO对数据“不敏感”,它要求SQL编写人员必须要了解各项细则;

    RBO一直沿用至ORACLE 9i,从ORACLE 10g开始,RBO已经彻底被抛弃。

    CBO:

    CBO是一种比RBO更加合理、可靠的优化器,在ORACLE 10g中完全取代RBO;

    CBO通过计算各种可能的执行计划的“代价”,即COST,从中选用COST最低的执行方案作为实际运行方案;

    它依赖数据库对象的统计信息,统计信息的准确与否会影响CBO做出最优的选择,也就是对数据“敏感”。

    ---------------------------------------------------------------------

    d) INDEX FAST FULL SCAN(索引快速扫描):

    扫描索引中的所有的数据块,与 INDEX FULL SCAN 类似,但是一个显著的区别是它不对查询出的数据进行排序(即数据不是以排序顺序被返回)

    e) INDEX SKIP SCAN(索引跳跃扫描)

    Oracle 9i后提供,有时候复合索引的前导列(索引包含的第一列)没有在查询语句中出现,oralce也会使用该复合索引,这时候就使用的INDEX SKIP SCAN;

    什么时候会触发 INDEX SKIP SCAN 呢?

    前提条件:表有一个复合索引,且在查询时有除了前导列(索引中第一列)外的其他列作为条件,并且优化器模式为CBO时

    当Oracle发现前导列的唯一值个数很少时,会将每个唯一值都作为常规扫描的入口,在此基础上做一次查找,最后合并这些查询;

    例如:

    假设表emp有ename(雇员名称)、job(职位名)、sex(性别)三个字段,并且建立了如 create index idx_emp on emp (sex, ename, job) 的复合索引;

    因为性别只有 '男' 和 '女' 两个值,所以为了提高索引的利用率,Oracle可将这个复合索引拆成 ('男', ename, job),('女', ename, job) 这两个复合索引;

    当查询 select * from emp where job = 'Programmer' 时,该查询发出后:

    Oracle先进入sex为'男'的入口,这时候使用到了 ('男', ename, job) 这条复合索引,查找 job = 'Programmer' 的条目;

    再进入sex为'女'的入口,这时候使用到了 ('女', ename, job) 这条复合索引,查找 job = 'Programmer' 的条目;

    最后合并查询到的来自两个入口的结果集。

    ----------------------------------------------

     

    2. 上图中的 NESTED LOOPS … 描述的是表连接方式;

    JOIN 关键字用于将两张表作连接,一次只能连接两张表,JOIN 操作的各步骤一般是串行的(在读取做连接的两张表的数据时可以并行读取);

    表(row source)之间的连接顺序对于查询效率有很大的影响,对首先存取的表(驱动表)先应用某些限制条件(Where过滤条件)以得到一个较小的row source,可以使得连接效率提高。

    -------------------------延伸阅读:驱动表(Driving Table)与匹配表(Probed Table)-------------------------

    驱动表(Driving Table):

    表连接时首先存取的表,又称外层表(Outer Table),这个概念用于 NESTED LOOPS(嵌套循环) 与 HASH JOIN(哈希连接)中;

    如果驱动表返回较多的行数据,则对所有的后续操作有负面影响,故一般选择小表(应用Where限制条件后返回较少行数的表)作为驱动表。

    匹配表(Probed Table):

    又称为内层表(Inner Table),从驱动表获取一行具体数据后,会到该表中寻找符合连接条件的行。故该表一般为大表(应用Where限制条件后返回较多行数的表)。

    ---------------------------------------------------------------------------------------------------------

    表连接的几种方式:

    • SORT MERGE JOIN(排序-合并连接)
    • NESTED LOOPS(嵌套循环)
    • HASH JOIN(哈希连接)
    • CARTESIAN PRODUCT(笛卡尔积)

    注:这里将首先存取的表称作 row source 1,将之后参与连接的表称作 row source 2

    (1) SORT MERGE JOIN(排序-合并连接)

    假设有查询:select a.name, b.name from table_A a join table_B b on (a.id = b.id)

    内部连接过程:

    a) 生成 row source 1 需要的数据,按照连接操作关联列(如示例中的a.id)对这些数据进行排序

    b) 生成 row source 2 需要的数据,按照与 a) 中对应的连接操作关联列(b.id)对数据进行排序

    c) 两边已排序的行放在一起执行合并操作(对两边的数据集进行扫描并判断是否连接)

    延伸:

    如果示例中的连接操作关联列 a.id,b.id 之前就已经被排过序了的话,连接速度便可大大提高,因为排序是很费时间和资源的操作,尤其对于有大量数据的表。

    故可以考虑在 a.id,b.id 上建立索引让其能预先排好序。不过遗憾的是,由于返回的结果集中包括所有字段,所以通常的执行计划中,即使连接列存在索引,也不会进入到执行计划中,除非进行一些特定列处理(如仅仅只查询有索引的列等)。

    排序-合并连接的表无驱动顺序,谁在前面都可以;

    排序-合并连接适用的连接条件有: <   <=   =   >   >= ,不适用的连接条件有: <>    like

    (2) NESTED LOOPS(嵌套循环)

    内部连接过程:

    a) 取出 row source 1 的 row 1(第一行数据),遍历 row source 2 的所有行并检查是否有匹配的,取出匹配的行放入结果集中

    b) 取出 row source 1 的 row 2(第二行数据),遍历 row source 2 的所有行并检查是否有匹配的,取出匹配的行放入结果集中

    c) ……

    若 row source 1 (即驱动表)中返回了 N 行数据,则 row source 2 也相应的会被全表遍历 N 次。

    因为 row source 1 的每一行都会去匹配 row source 2 的所有行,所以当 row source 1 返回的行数尽可能少并且能高效访问 row source 2(如建立适当的索引)时,效率较高。

    延伸:

    嵌套循环的表有驱动顺序,注意选择合适的驱动表。

    嵌套循环连接有一个其他连接方式没有的好处是:可以先返回已经连接的行,而不必等所有的连接操作处理完才返回数据,这样可以实现快速响应。

    应尽可能使用限制条件(Where过滤条件)使驱动表(row source 1)返回的行数尽可能少,同时在匹配表(row source 2)的连接操作关联列上建立唯一索引(UNIQUE INDEX)或是选择性较好的非唯一索引,此时嵌套循环连接的执行效率会变得很高。若驱动表返回的行数较多,即使匹配表连接操作关联列上存在索引,连接效率也不会很高。

    (3)HASH JOIN(哈希连接) :

    哈希连接只适用于等值连接(即连接条件为  =  )

    HASH JOIN对两个表做连接时并不一定是都进行全表扫描,其并不限制表访问方式;

    内部连接过程简述:

    a) 取出 row source 1(驱动表,在HASH JOIN中又称为Build Table) 的数据集,然后将其构建成内存中的一个 Hash Table(Hash函数的Hash KEY就是连接操作关联列),创建Hash位图(bitmap)

    b) 取出 row source 2(匹配表)的数据集,对其中的每一条数据的连接操作关联列使用相同的Hash函数并找到对应的 a) 里的数据在 Hash Table 中的位置,在该位置上检查能否找到匹配的数据

    ----------------延伸阅读:Hash Table相关----------------

    来自Wiki的解释:

    In computing, a hash table (hash map) is a data structure used to implement an associative array, a structure that can map keys to values. A hash table uses a hash function to compute an index into an array of buckets or slots, from which the desired value can be found.

    散列(hash)技术:在记录的存储位置和记录具有的关键字key之间建立一个对应关系 f ,使得输入key后,可以得到对应的存储位置 f(key),这个对应关系 就是散列(哈希)函数;

    采用散列技术将记录存储在一块连续的存储空间中,这块连续的存储空间就是散列表(哈希表);

     不同的key经同一散列函数散列后得到的散列值理论上应该不同,但是实际中有可能相同,相同时即是发生了散列(哈希)冲突,解决散列冲突的办法有很多,比如HashMap中就是用链地址法来解决哈希冲突;

    哈希表是一种面向查找的数据结构,在输入给定值后查找给定值对应的记录在表中的位置以获取特定记录这个过程的速度很快。

    --------------------------------------------------------

    HASH JOIN的三种模式:

    • OPTIMAL HASH JOIN
    • ONEPASS HASH JOIN
    • MULTIPASS HASH JOIN

    1) OPTIMAL HASH JOIN

    OPTIMAL 模式是从驱动表(也称Build Table)上获取的结果集比较小,可以把根据结果集构建的整个Hash Table都建立在用户可以使用的内存区域里。

    optimal_hash_join

    连接过程简述:

    Ⅰ:首先对Build Table内各行数据的连接操作关联列使用Hash函数,把Build Table的结果集构建成内存中的Hash Table。如图所示,可以把Hash Table看作内存中的一块大的方形区域,里面有很多的小格子,Build Table里的数据就分散分布在这些小格子中,而这些小格子就是Hash Bucket(见上面Wiki的定义)。

    Ⅱ:开始读取匹配表(Probed Table)的数据,对其中每行数据的连接操作关联列都使用同上的Hash函数,定位Build Table里使用Hash函数后具有相同值数据所在的Hash Bucket。

    Ⅲ:定位到具体的Hash Bucket后,先检查Bucket里是否有数据,没有的话就马上丢掉匹配表(Probed Table)的这一行。如果里面有数据,则继续检查里面的数据(驱动表的数据)是否和匹配表的数据相匹配。

    2): ONEPASS HASH JOIN :

    从驱动表(也称Build Table)上获取的结果集较大,无法将根据结果集构建的Hash Table全部放入内存中时,会使用 ONEPASS 模式。

    one_pass_hash_join

    连接过程简述:

    Ⅰ:对Build Table内各行数据的连接操作关联列使用Hash函数,根据Build Table的结果集构建Hash Table后,由于内存无法放下所有的Hash Table内容,将导致有的Hash Bucket放在内存里,有的Hash Bucket放在磁盘上,无论放在内存里还是磁盘里,Oracle都使用一个Bitmap结构来反映这些Hash Bucket的状态(包括其位置和是否有数据)。

    Ⅱ:读取匹配表数据并对每行的连接操作关联列使用同上的Hash函数,定位Bitmap上Build Table里使用Hash函数后具有相同值数据所在的Bucket。如果该Bucket为空,则丢弃匹配表的这条数据。如果不为空,则需要看该Bucket是在内存里还是在磁盘上。

    如果在内存中,就直接访问这个Bucket并检查其中的数据是否匹配,有匹配的话就返回这条查询结果。

    如果在磁盘上,就先把这条待匹配数据放到一边,将其先暂存在内存里,等以后积累了一定量的这样的待匹配数据后,再批量的把这些数据写入到磁盘上(上图中的 Dump probe partitions to disk)。

    Ⅲ:当把匹配表完整的扫描了一遍后,可能已经返回了一部分匹配的数据了。接下来还有Hash Table中一部分在磁盘上的Hash Bucket数据以及匹配表中部分被写入到磁盘上的待匹配数据未处理,现在Oracle会把磁盘上的这两部分数据重新匹配一次,然后返回最终的查询结果。

    3): MULTIPASS HASH JOIN

    当内存特别小或者相对而言Hash Table的数据特别大时,会使用 MULTIPASS 模式。MULTIPASS会多次读取磁盘数据,应尽量避免使用该模式。

     

    3. 上图中的 … OUTER 描述的是表连接类型;

    表连接的两种类型:

    • INNER JOIN(内连接)
    • OUTER JOIN(外连接)

    示例数据说明:

    现有A、B两表,A表信息如下:

    table_A

    B表信息如下:

    table_B

    下面的例子都用A、B两表来演示。

    (1) INNER JOIN(内连接)

    只返回两表中相匹配的记录

    INNER JOIN 又分为两种:

    • 等值连接(连接条件为  
    • 非等值连接(连接条件为 非 =  ,如  >  >=  <  <=  等)

    等值连接用的最多,下面以等值连接举例:

    内连接的两种写法:

    Ⅰ: select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a inner join B b on (a.id = b.id)

    Ⅱ: select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a join B b on (a.id = b.id)

    连接时只返回满足连接条件(a.id = b.id)的记录:

    inner_join

    (2) OUTER JOIN(外连接)

    OUTER JOIN 分为三种:

    • LEFT OUTER JOIN(可简写为 LEFT JOIN,左外连接)
    • RIGHT OUTER JOIN( RIGHT JOIN,右外连接)
    • FULL OUTER JOIN( FULL JOIN,全外连接)

    a) LEFT JOIN(左连接)

    返回的结果不仅包含符合连接条件的记录,还包含左边表中的全部记录。(若返回的左表中某行记录在右表中没有匹配项,则右表中的返回列均为空值)

    两种写法:

    Ⅰ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a left outer join B b on (a.id = b.id)

    Ⅱ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a left join B b on (a.id = b.id)

    返回结果:

    left_join

    b) RIGHT JOIN(右连接)

    返回的结果不仅包含符合连接条件的记录,还包含右边表中的全部记录。(若返回的右表中某行记录在左表中没有匹配项,则左表中的返回列均为空值)

    两种写法:

    Ⅰ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a right outer join B b on (a.id = b.id)

    Ⅱ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a right join B b on (a.id = b.id)

    返回结果:

    right_join

    c) FULL JOIN(全连接)

    返回左右两表的全部记录。(左右两边不匹配的项都以空值代替)

    两种写法:

    Ⅰ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a full outer join B b on (a.id = b.id)

    Ⅱ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a full join B b on (a.id = b.id)

    返回结果:

    full_join

    ---------------------延伸阅读: (+) 操作符-------------------

    (+) 操作符是Oracle特有的表示法,用来表示外连接(只能表示 左外、右外 连接),需要配合Where语句使用。

    特别注意:(+) 操作符在左表的连接条件上表示右连接,在右表的连接条件上表示左连接

    如:

    Ⅰ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a, B b where a.id = b.id(+)

    查询结果:

    右边( )

    实际与左连接 select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a left join B b on (a.id = b.id) 效果等价

    Ⅱ:select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a, B b where a.id(+) = b.id

    查询结果:

    左边( )

    实际与右连接 select a.id A_ID, a.name A_NAME, b.id B_ID, b.name B_NAME from A a right join B b on (a.id = b.id) 效果等价

    本文转自:https://www.cnblogs.com/Dreamer-1/p/6076440.html


    展开全文
  • 数据库SQL执行计划

    千次阅读 2018-10-11 23:40:13
    什么是Mysql的执行计划 要对执行计划有个比较好的理解,需要先对MySQL的基础结构及查询基本原理有简单的了解。 一条SQL如何执行?大概过程 MySQL本身的功能架构分为三个部分,分别是 应用层、逻辑层、物理层,不只是...

    能写sql 只是程序员的基本功,能写出性能优异的SQL是优秀程序员的必备技能

    什么是Mysql的执行计划

    要对执行计划有个比较好的理解,需要先对MySQL的基础结构及查询基本原理有简单的了解。

    一条SQL如何执行?大概过程

    MySQL本身的功能架构分为三个部分,分别是 应用层、逻辑层、物理层,不只是MySQL ,其他大多数数据库产品都是按这种架构来进行划分的。

    • 应用层,主要负责与客户端进行交互,建立链接,记住链接状态,返回数据,响应请求,这一层是和客户端打交道的。

    • 逻辑层,主要负责查询处理、事务管理等其他数据库功能处理,以查询为例。

      • 首先接受到查询sql之后,数据库会立即分配一个线程对其进行处理;
      • 第一步查询处理器会对SQL查询进行优化,优化后会生成执行计划;
      • 然后交由计划执行器来执行。
      • 计划执行器需要访问更底层的事务管理器,存储管理器来操作数据,他们各自的分工各有不同;
      • 最终通过调用物理层的文件获取到查询结构信息,将最终结果响应给应用层。
    • 物理层,实际物理磁盘上存储的文件,主要分为数据文件,日志文件

    通过上面的描述,生成执行计划是执行一条SQL必不可少的步骤,一条SQL性能的好坏,可以通过查看执行计划很直观的看出来,执行计划提供了各种查询类型与级别,方面我们进行查看以及为作为性能分析的依据。

    所谓的执行计划,就是mysql如何执行一条Sql语句,包括sql查询的顺序、是否使用索引、以及使用索引信息的等等。

    如何分析执行计划,来帮助我们写出更好的Sql

    MySQL为我们提供了 explain 关键字来直观的查看一条SQL的执行计划。

    //1. 查询table_name
    select * from table_name where name="explain";
    
    //2. 查看上述语句的执行计划
    explain select * from table_name where name="explain";
    

    执行查看上述2语句后,我们可以得出以下执行计划结果

    id select_type table partitions type possible_keys key key_len ref rows Extra
    1 SIMPLE table_name ALL 1 Using where

    上面这个执行计划给到的信息是: 这个结果通过一个简单的语句全表扫描,共扫描1行,使用where条件在t_base_user表中筛选出的。


    要想看懂执行计划,就要明白每一个参数的含义

    id select_type table partitions type possible_keys key key_len ref rows Extra

    id

    有一组数字组成。表示一个查询中各个子查询的执行顺序;

    • id相同执行顺序由上至下。

    image

    • id不同,id值越大优先级越高,越先被执行。

    image

    • id为null时表示一个结果集,不需要使用它查询,常出现在包含union等查询语句中。

    image

    select_type

    每个子查询的查询类型,一些常见的查询类型。

    id select_type description
    1 SIMPLE 不包含任何子查询或union等查询
    2 PRIMARY 包含子查询最外层查询就显示为 PRIMARY
    3 SUBQUERY 在select或 where字句中包含的查询
    4 DERIVED from字句中包含的查询
    5 UNION 出现在union后的查询语句中
    6 UNION RESULT 从UNION中获取结果集,例如上文的第三个例子

    table

    表示该语句查询的表

    partitions

    表分区、表创建的时候可以指定通过那个列进行表分区。 ex:

    create table tmp (
        id int unsigned not null AUTO_INCREMENT,
        name varchar(255),
        PRIMARY KEY (id)
    ) engine = innodb
    partition by key (id) partitions 5;
    

    image

    type

    访问类型

    • ALL 扫描全表数据
    • index 遍历索引
    • range 索引范围查找
    • index_subquery 在子查询中使用 ref
    • unique_subquery 在子查询中使用 eq_ref
    • ref_or_null对Null进行索引的优化的 ref
    • fulltext 使用全文索引
    • ref 使用非唯一索引查找数据
    • eq_refjoin查询中使用RIMARY KEY or UNIQUE NOT NULL索引关联。
    • const 使用主键或者唯一索引,且匹配的结果只有一条记录。
    • system const 连接类型的特例,查询的表为系统表。

    image

    possible_keys

    查询涉及到的字段上若存在索引,则该索引将被列出来。当该列为 NULL时就要考虑当前的SQL是否需要优化了。可能使用的索引,注意不一定会使用。

    key

    显示MySQL在查询中实际使用的索引,若没有使用索引,显示为NULL。

    Tips:查询中若使用了覆盖索引(覆盖索引:索引的数据覆盖了需要查询的所有数据),则该索引仅出现在key列表中

    key_length

    索引长度 char()、varchar()索引长度的计算公式:

    (Character Set:utf8mb4=4,utf8=3,gbk=2,latin1=1) * 列长度 + 1(允许null) + 2(变长列)
    

    其他类型索引长度的计算公式: ex:

    CREATE TABLE `student` (
      `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
      `name` varchar(128) NOT NULL DEFAULT '',
      `age` int(11),
      PRIMARY KEY (`id`),
      UNIQUE KEY `idx` (`name`),
      KEY `idx_age` (`age`)
    ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
    
    

    name 索引长度为: 编码为utf8mb4,列长为128,不允许为NULL,字段类型为varchar(128)。key_length = 128 * 4 + 0 + 2 = 514;

    image

    age 索引长度:int类型占4位,允许null,索引长度为5。
    image

    ref

    表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值

    rows

    扫描行数,也就是说,需要扫描多少行,采能获取目标行数,一般情况下会大于返回行数。通常情况下,rows越小,效率越高,也就有大部分SQL优化,都是在减少这个值的大小。

    Tips: 理想情况下扫描的行数与实际返回行数理论上是一致的,但这种情况及其少,如关联查询,扫描的行数就会比返回行数大大增加)

    extra

    extra的信息非常丰富,常见的有:

    • 1.Using index 使用覆盖索引
    • 2.Using where 使用了用where子句来过滤结果集
    • 3.Using filesort 使用文件排序,使用非索引列进行排序时出现,非常消耗性能,尽量优化。
    • 4.Using temporary 使用了临时表

    参考blog → 彻底读懂Mysql执行计划

    展开全文
  • SQLServer执行计划

    2019-09-22 10:00:50
    大哥提交的sql语句,数据库查询优化器,经过分析生成多个数据库可以识别的高效执行查询方式。然后优化器会在众多执行计划中找出一个资源使用最少,而不是最快的执行方案,给你展示出来,可以是xml格式,文本格式,也...

    执行计划简介

    1、什么是执行计划?

    大哥提交的sql语句,数据库查询优化器,经过分析生成多个数据库可以识别的高效执行查询方式。然后优化器会在众多执行计划中找出一个资源使用最少,而不是最快的执行方案,给你展示出来,可以是xml格式,文本格式,也可以是图形化的执行方案。

    2、预估执行计划,实际执行计划

    选择语句,点击上面其中一个执行计划,预估执行计划可以立即显示,而实际执行计划则需要执行sql语句后出现。预估执行计划不等于实际执行计划,但是绝大多数情况下实际的执行计划跟预估执行计划都是一致的。统计信息变更或者执行计划重编译等情况下,会造成不同。

    3、为什么要读懂执行计划

    首先执行计划让你知道你复杂的sql到底是怎么执行的,有没有按照你想的方案执行,有没有按照最高效的方式执行,使用啦众多索引的哪一个,怎么排序,怎么合并数据的,有没有造成不必要资源浪费等等。官方数据显示,执行t-sql存在问题,80%都可以在执行计划中找到答案。

    4、针对图形化执行计划分析

    执行计划,可以以文本,xml,图形化展示出来。本骗主要以图形化执行计划主导进行分析,然而执行计划中包含78个可用的操作符,本篇也只能对常用的进行分析,常用的几乎就包含你日常所有的了。Msdn上有图片介绍:https://msdn.microsoft.com/zh-cn/library/ms175913(v=sql.90).aspx

    5、怎么看执行计划

    图形化执行计划是从上到下从又到左看的。

    6、清除缓存的执行计划

    dbcc freeprocache

    dbcc flushprocindb(db_id)

    看懂图形化执行计划

    1、连线

    1、越粗表示扫描影响的行数愈多。

    2、Actual Number of Rows  扫描中实际影响的的行数。

    3、Estimated Number of Rows 预估扫描影响的行数。

    4、Estimated row size 操作符生成的行的估计大小(字节)。

    5、Estimated Data Size 预估影响的数据的大小。

    2、Tooltips,当前步骤执行信息

      

    Note:这个tips的信息告诉我们执行的对象是什么,采用的操作操作是什么,查找的数据是什么,使用的索引是什么,排序与否,预估cpu、I/O、影响行数,实际行数等信息。具体参数清单参见msdn:https://msdn.microsoft.com/zh-cn/library/ms178071(v=sql.90).aspx

    3、Table Scan(表扫描)

    当表中没有聚集索引,又没有合适索引的情况下,会出现这个操作。这个操作是很耗性能的,他的出现也意味着优化器要遍历整张表去查找你所需要的数据。

    4、Clustered Index Scan(聚集索引扫描)、Index Scan(非聚集索引扫描)

     

    这个图标两个操作都可以使用,一个聚集索引扫描,一个是非聚集索引扫描。

    聚集索引扫描:聚集索引的数据体积实际是就是表本身,也就是说表有多少行多少列,聚集所有就有多少行多少列,那么聚集索引扫描就跟表扫描差不多,也要进行全表扫描,遍历所有表数据,查找出你想要的数据。

    非聚集索引扫描:非聚集索引的体积是根据你的索引创建情况而定的,可以只包含你要查询的列。那么进行非聚集索引扫描,便是你非聚集中包含的列的所有行进行遍历,查找出你想要的数据。

    5、Key Lookup(键值查找)

    首先需要说的是查找,查找与扫描在性能上完全不是一个级别的,扫描需要遍历整张表,而查找只需要通过键值直接提取数据,返回结果,性能要好。

    当你查找的列没有完全被非聚集索引包含,就需要使用键值查找在聚集索引上查找非聚集索引不包含的列。

    6、RID Lookoup(RID查找)

     

    跟键值查找类似,只不过RID查找,是需要查找的列没有完全被非聚集索引包含,而剩余的列所在的表又不存在聚集索引,不能键值查找,只能根据行表示Rid来查询数据。

    7、Clustered Index Seek(聚集索引查找)、Index Seek(非聚集索引查找)

    聚集索引查找和非聚集索引查找都是使用该图标。

    聚集索引查找:聚集索引包含整个表的数据,也就是在聚集索引的数据上根据键值取数据。

    非聚集索引查找:非聚集索引包含创建索引时所包含列的数据,在这些非聚集索引的数据上根据键值取数据。

    8、Hash Match

     

    这个图标有两种地方用到,一种是表关联,一种是数据聚合运算时。

    再分别说这两中运算的前面,我先说说Hashing(编码技术)和Hash Table(数据结构)。

    Hashing:在数据库中根据每一行的数据内容,转换成唯一符号格式,存放到临时哈希表中,当需要原始数据时,可以给还原回来。类似加密解密技术,但是他能更有效的支持数据查询。

    Hash Table:通过hashing处理,把数据以key/value的形式存储在表格中,在数据库中他被放在tempdb中。

    接下来,来说说Hash Math的表关联跟行数据聚合是怎么操作运算的。

    表关联:

    如上图,关联两个数据集时,Hash Match会把其中较小的数据集,通过Hashing运算放入HashTable中,然后一行一行的遍历较大的数据集与HashTable进行相应的匹配拉取数据。

    数据聚合:当查询中需要进行Count/Sum/Avg/Max/Min时,数据可能会采用把数据先放在内存中的HashTable中然后进行运算。

    9、Nested Loops

    这个操作符号,把两个不同列的数据集汇总到一张表中。提示信息中的Output List中有两个数据集,下面的数据集(inner set)会一一扫描与上面的数据集(out set),知道扫描完为止,这个操作才算是完成。

    10、Merge Join

    这种关联算法是对两个已经排过序的集合进行合并。如果两个聚合是无序的则将先给集合排序再进行一一合并,由于是排过序的集合,左右两个集合自上而下合并效率是相当快的。

    11、Sort(排序)

    对数据集合进行排序,需要注意的是,有些数据集合在索引扫描后是自带排序的。

    12、Filter(筛选)

    根据出现在having之后的操作运算符,进行筛选

    13、Computer Scalar

     

    在需要查询的列中需要自定义列,比如count(*) as cnt ,select name+''+age 等会出现此符号。

    根据执行计划细节要做的优化操作

    这里会有很多建议给出,我不一一举例了,给出几个示例,想做到优化行家,多的还需要大家去悟去理解。

    1、如果select * 通常情况下聚集索引会比非聚集索引更优。

    2、如果出现Nested Loops,需要查下是否需要聚集索引,非聚集索引是否可以包含所有需要的列。

    3、Hash Match连接操作更适合于需要做Hashing算法集合很小的连接。

    4、Merge Join时需要检查下原有的集合是否已经有排序,如果没有排序,使用索引能否解决。

    5、出现表扫描,聚集索引扫描,非聚集索引扫描时,考虑语句是否可以加where限制,select * 是否可以去除不必要的列。

    6、出现Rid查找时,是否可以加索引优化解决。

    7、在计划中看到不是你想要的索引时,看能否在语句中强制使用你想用的索引解决问题,强制使用索引的办法Select CluName1,CluName2 from Table with(index=IndexName)。

    8、看到不是你想要的连接算法时,尝试强制使用你想要的算法解决问题。强制使用连接算法的语句:select * from t1 left join t2 on t1.id=t2.id option(Hash/Loop/Merge Join)

    9、看到不是你想要的聚合算法是,尝试强制使用你想要的聚合算法。强制使用聚合算法的语句示例:select  age ,count(age) as cnt from t1 group by age  option(order/hash group)

    10、看到不是你想要的解析执行顺序是,或这解析顺序耗时过大时,尝试强制使用你定的执行顺序。option(force order)

    11、看到有多个线程来合并执行你的sql语句而影响到性能时,尝试强制是不并行操作。option(maxdop 1)

    12、在存储过程中,由于参数不同导致执行计划不同,也影响啦性能时尝试指定参数来优化。option(optiomize for(@name='zlh'))

    13、不操作多余的列,多余的行,不做务必要的聚合,排序。

    转载于:https://www.cnblogs.com/zhaoyl9/p/11454051.html

    展开全文
  • 生产数据库中经常出现SQL语句走错执行计划的情况,如果该sqlid还有其他高效执行计划,可以通过coe_xfr_sql_profile.sql脚本进行绑定,但是如果sqlid没有高效执行计划,就需要通过自己手工生成一个执行计划(通过...

    生产数据库中经常出现SQL语句走错执行计划的情况,如果该sqlid还有其他高效的执行计划,可以通过coe_xfr_sql_profile.sql脚本进行绑定,但是如果sqlid没有高效的执行计划,就需要通过自己手工生成一个执行计划(通过加hint,或者其他方法),然后将手工生成的 执行计划绑定到生产中运行的sqlid上,下面就演示下具体方法:
    –下面SQL正常走ob.object_id列上的索引IDX1_OB
    select ob.owner,ob.object_name from ob,tt where ob.object_id = tt.object_id and tt.name = ‘a255’;

    通过baseline绑定到下面SQL语句的执行计划上
    select /+full(ob)/ ob.owner,ob.object_name from ob,tt where /fengsongtao/ ob.object_id = tt.object_id and tt.name = ‘a255’;

    1、查看当前sql的SQL_ID和PLAN_HASH_VALUE
    select sql_id,plan_hash_value,sql_text,parse_calls,executions from v$sql where sql_text like ‘select ob.owner,ob.object_name from ob,tt where ob.object_id = tt.object_id and%’;

    SQL_ID: cw9ykcy4nxagr
    PLAN_HASH_VALUE: 4294070672

    2、根据上面的SQL_ID和PLAN_HASH_VALUE生成SQL_HANDLE
    –创建baseline
    declare
    l_pls number;
    begin
    l_pls := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => ‘cw9ykcy4nxagr’,
    plan_hash_value => 4294070672,
    enabled => ‘NO’); --注意这里是no
    end;
    /
    –查看生成的baseline
    select sql_handle,
    plan_name,
    origin,
    enabled,
    accepted,
    fixed,
    creator,
    optimizer_cost,
    sql_text
    from dba_sql_plan_baselines
    where origin = ‘MANUAL-LOAD’
    order by created desc;

    SQL_HANDLE: SQL_e869f85cdf464308
    PLAN_NAME: SQL_PLAN_fhugsbmgnchs8ee1114be

    3、手工生成需要的执行计划
    –多次执行下面sql
    select /+full(ob)/ ob.owner,ob.object_name from ob,tt where /fengsongtao/ ob.object_id = tt.object_id and tt.name = ‘a255’;

    SQL_ID: 232n5typ7xcmd
    PLAN_HASH_VALUE: 1115602488

    —将原sql的sql_handle与正确的执行计划(手工生成的sql_id和plan_hash_value)做关联
    declare
    l_pls number;
    begin
    l_pls := DBMS_SPM.load_plans_from_cursor_cache(sql_id => ‘232n5typ7xcmd’, – new sql_id
    plan_hash_value => 1115602488, --new plan_hash_value
    sql_handle => ‘SQL_e869f85cdf464308’ --原sql的sql_handle
    );
    end;
    /

    4、删除原来的的执行计划
    –查看原sql对应的sql_handle有两个执行计划(plan_name)
    select sql_handle, plan_name, origin, enabled, accepted,fixed,creator,optimizer_cost,sql_text
    from dba_sql_plan_baselines where origin = ‘MANUAL-LOAD’ and sql_handle=‘SQL_e869f85cdf464308’;

    SQL_e869f85cdf464308 --> SQL_PLAN_fhugsbmgnchs8ee1114be --原执行计划
    SQL_e869f85cdf464308 --> SQL_PLAN_fhugsbmgnchs8b10f07f0 --手工生成的执行计划

    –查看两个执行计划的具体内容如下:
    select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle=>‘SQL_e869f85cdf464308’,plan_name=>‘SQL_PLAN_fhugsbmgnchs8ee1114be’));


    SQL handle: SQL_e869f85cdf464308
    SQL text: select ob.owner,ob.object_name from ob,tt where ob.object_id =
    tt.object_id and tt.name = ‘a255’


    Plan name: SQL_PLAN_fhugsbmgnchs8ee1114be Plan id: 3994096830
    Enabled: NO Fixed: NO Accepted: YES Origin: MANUAL-LOAD

    Plan hash value: 4294070672


    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

    | 0 | SELECT STATEMENT | | 65988 | 6830K| 33 (0)| 00:00:01 |
    | 1 | NESTED LOOPS | | 65988 | 6830K| 33 (0)| 00:00:01 |
    | 2 | NESTED LOOPS | | 65988 | 6830K| 33 (0)| 00:00:01 |
    |* 3 | TABLE ACCESS FULL | TT | 1 | 10 | 3 (0)| 00:00:01 |
    |* 4 | INDEX RANGE SCAN | IDX1_OB | 32 | | 2 (0)| 00:00:01 |
    | 5 | TABLE ACCESS BY INDEX ROWID| OB | 63450 | 5948K| 30 (0)| 00:00:01 |

    Predicate Information (identified by operation id):

    3 - filter(“TT”.“NAME”=‘a255’)
    4 - access(“OB”.“OBJECT_ID”=“TT”.“OBJECT_ID”)

    select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle=>‘SQL_e869f85cdf464308’,plan_name=>‘SQL_PLAN_fhugsbmgnchs8b10f07f0’));


    SQL handle: SQL_e869f85cdf464308
    SQL text: select ob.owner,ob.object_name from ob,tt where ob.object_id =
    tt.object_id and tt.name = ‘a255’


    Plan name: SQL_PLAN_fhugsbmgnchs8b10f07f0 Plan id: 2970552304
    Enabled: YES Fixed: NO Accepted: YES Origin: MANUAL-LOAD

    Plan hash value: 1115602488


    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

    | 0 | SELECT STATEMENT | | 65988 | 6830K| 5493 (1)| 00:01:06 |
    |* 1 | HASH JOIN | | 65988 | 6830K| 5493 (1)| 00:01:06 |
    |* 2 | TABLE ACCESS FULL| TT | 1 | 10 | 3 (0)| 00:00:01 |
    | 3 | TABLE ACCESS FULL| OB | 1649K| 151M| 5485 (1)| 00:01:06 |

    Predicate Information (identified by operation id):

    1 - access(“OB”.“OBJECT_ID”=“TT”.“OBJECT_ID”)
    2 - filter(“TT”.“NAME”=‘a255’)

    –删除原来的的执行计划
    declare
    l_pls number;
    begin
    l_pls := DBMS_SPM.DROP_SQL_PLAN_BASELINE(sql_handle => ‘SQL_e869f85cdf464308’, --sql_handle_for_original
    plan_name => ‘SQL_PLAN_fhugsbmgnchs8ee1114be’ --sql_plan_name_for_original
    );
    end;
    /

    –再次查看
    select sql_handle,
    plan_name,
    origin,
    enabled,
    accepted,
    fixed,
    creator,
    optimizer_cost,
    sql_text
    from dba_sql_plan_baselines
    where origin = ‘MANUAL-LOAD’
    and sql_handle = ‘SQL_e869f85cdf464308’

    展开全文
  • MongoDB执行计划

    千次阅读 2017-08-20 22:24:32
    mongoDB系统了explain()方法,用来查看其执行计划和其统计信息。二 explain三种模式1、queryPlanner queryPlanner是explain的默认模式,queryPlanner模式下并不会去真正进行操作语句的执行,而是针对que
  • SqlServer执行计划

    千次阅读 2018-11-15 09:26:47
    1、看懂t-sql的执行计划,明白执行计划中的一些常识。 2、能够分析执行计划,找到优化sql性能的思路或方案。 如果你对sql查询优化的理解或常识不是很深入,那么推荐几骗博文给你:SqlServer性能检测和优化工具使用...
  • sqlserver 执行计划

    千次阅读 2019-05-31 16:24:28
    一个很好的手册分享,执行计划里的属性解释官方文档:...想复杂的事情简单说,在看执行计划的其他文章的时候,发现直接上很复杂的DDL脚本来讲解,这样...
  • 执行计划

    2011-09-27 22:15:48
    所谓执行计划,顾名思义,就是对一个查询任务,做出一份怎样去完成任务的详细方案。举个生活中的例子,我从珠海要去英国,我可以选择 先去香港然后转机,也可先去北京转机,或者去广州也可以。但是到底怎么去英国...
  • Oracle的执行计划

    2013-03-19 23:39:38
    今天来详细说说Oracle的执行计划,所谓执行计划,就是在执行某条SQL之前作出的执行方案,或者说是执行路径。Oracle的优化器模式有两大类,一个是基于规则的(RBO:Rule Based Optimizer),一个是基于代价的优化器...
  • ORACLE执行计划学习总结

    千次阅读 2016-04-06 18:54:01
    如何看懂ORACLE执行计划 一、什么是执行计划 An explain plan is a representation of the access path that is taken when a query is executed within Oracle. 二、如何访问数据 At the physical level Oracle ...
  • MSSQLSERVER执行计划详解

    千次阅读 2018-05-15 11:30:54
    序言本篇主要目的有二:1、看懂t-sql的执行计划,明白执行计划中的一些常识。2、能够分析执行计划,找到优化sql性能的思路或方案。如果你对sql查询优化的理解或常识不是很深入,那么推荐几骗博文给你:SqlServer性能...
  • MySQL 执行计划和MySQL执行过程

    千次阅读 2018-07-30 18:13:53
    SQL执行计划 数据库服务器在执行sql语句的时候,会准备几套方案,最后选择消耗资源最小的那个方案。   MYSQL架构图:   MYSQL执行流程 客户端连接服务器。 查询缓存。不会直接查询数据库。会从缓存中查看...
  • 获取执行计划

    2011-04-21 22:32:00
    处理执行计划需要采取以下三步:获取、解释、判定效率 获取执行计划: -执行SQL语句EXPLAIN PLAN,然后查询结果输出表 -查询一张动态性能视图,它显示缓存在库缓存中的执行计划 -查询自动...
  • DB2执行计划浅析

    千次阅读 2017-05-02 17:10:00
    在数据库调优过程中,SQL语句往往是导致性能问题的主要原因,而执行计划则是解释SQL语句执行过程的语言,只有充分读懂执行计划才能在数据库性能优化中做到游刃有余。 常见的关系型数据库中,虽然执行计划的表示方法...
  • 我们知道,查询优化器的基本的目标就是为我们的查询语句找出一个比较高效执行计划。即使是一个非常简单的查询,也会存在很多的不同方式去访问数据,而这些不同的方式都是可以得到相同的结果的,所以,查询优化器...
  • Oracle总结(一):Oracle执行计划

    千次阅读 2019-01-15 11:25:11
    看懂Oracle执行计划 最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的...2.怎样查看Oracle执行计划? 因为我一直用的PLSQL远程连接的公司数据库,所以这里以PLSQL为例: 2.1配置执行计划需要显示的项: 工具...
  • Oracle执行计划详解

    2013-03-12 13:41:39
    所谓执行计划,顾名思义,就是对一个查询任务,做出一份怎样去完成任务的详细方案。举个生活中的例子,我从珠海要去英国,我可以选择先去香港然后转机,也可以先去北京转机,或者去广州也可以。但是到底怎样去英国...
  • 报告式(计划)确认 复述式确认 建议式确认 领会意图不跑偏 1)同一高度 大局思维 政策水平 战略眼光 2)同等基础 摸透全面情况 掌握中心工作 清楚主要问题 3)同向思考 工作开始前 及时提建议 ...
  • oracle执行计划

    2013-09-06 16:34:42
    1,什么是执行计划所谓执行计划,顾名思义,就是对一个查询任务,做出一份怎样去完成任务的详细方案。举个生活中的例子,我从珠海要去英国,我可以选择先去香港然后转机,也可以先去北京转机,或者去广州也可以。...
  • oracle执行计划与效率

    千次阅读 2018-04-03 09:22:55
     二:怎样查看Oracle执行计划?以PLSQL为例:执行计划的常用列字段解释:基数(Rows):Oracle估计的当前操作的返回结果集行数字节(Bytes):执行该步骤后返回的字节数耗费(COST)、CPU耗费:Oracle估计的该步骤...
  • 第五章 执行计划详解

    2019-11-27 17:03:56
    gp 是基于 pgsql 开发的,其执行计划大多是跟 pgsql 一样的,但由于 gp 是分布式并行数据库,在 sql 执行上有很多 MPP 的痕迹,因此在理解 gp 的执行计划时,一定要将其分布式框架熟读在心,从而能够通过调整执行...
  • 看懂Oracle执行计划

    千次阅读 多人点赞 2018-03-06 11:46:06
    执行计划是一条查询语句在Oracle中的执行过程或访问路径的描述 二:怎样查看Oracle执行计划?因为我一直用的PLSQL远程连接的公司数据库,所以这里以PLSQL为例:①:配置执行计划需要显示的项:工具 —&gt; 首...
  • oracle执行计划相关

    千次阅读 2016-10-14 23:51:32
    sql执行计划对于sql执行效率是至关重要的,所以对于程序开发人员和DBA而言,了解一下sql执行计划都是很有好处的。什么是执行计划sql是一种声明性语言,它和我们平时常用的c,java这些命令性语言差别很大,声明性语言...
  • SSMS执行计划对比功能

    2017-02-27 13:30:56
    问题引入 “鸟儿,我一直有个疑问,在很多时候,被客户问道,为什么非常相似的...“那如何高效的对比执行计划的差异呢?”老鸟穷追猛问。“这个嘛,我自有妙招,且听我细细道来”。 问题分析 SSMS图形化展示SQL Serv...
  • Oracle执行计划 explain plan 详解

    千次阅读 2014-10-17 15:34:33
    Oracle执行计划详解 --- 本人 作者:TTT BLOG 本文地址:http://blog.chinaunix.net/u3/107265/showart_2192657.html --- 简介:  本文全面详细介绍oracle执行计划的相关的概念,访问...
  • 该语句一直以来都比较高效执行计划用了索引范围扫描后经历三次嵌套循环,可在2秒内返回结果,但今天经同事反映却走了1分多钟! 原SQL语句: Select * From (Select Rownum As Rownumber__, t.* From (Select T1...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 98,187
精华内容 39,274
关键字:

怎样高效执行计划