使用plsql执行计划进行sql调优

一段SQL代码写好以后,可以通过查看SQL的执行计划,初步预测该SQL在运行时的性能好坏,尤其是在发现某个SQL语句的效率较差时,我们可以通过查看执行计划,分析出该SQL代码的问题所在。

那么,作为开发人员,怎么样比较简单的利用执行计划评估SQL语句的性能呢?总结如下步骤供大家参考:

1、 打开熟悉的查看工具:PL/SQL Developer。

在PL/SQL Developer中写好一段SQL代码后,按F5,PL/SQL
Developer会自动打开执行计划窗口,显示该SQL的执行计划。

2、 查看总COST,获得资源耗费的总体印象

一般而言,执行计划第一行所对应的COST(即成本耗费)值,反应了运行这段SQL的总体估计成本,单看这个总成本没有实际意义,但可以拿它与相同逻辑不同执行计划的SQL的总体COST进行比较,通常COST低的执行计划要好一些。

3、 按照从左至右,从上至下的方法,了解执行计划的执行步骤

执行计划按照层次逐步缩进,从左至右看,缩进最多的那一步,最先执行,如果缩进量相同,则按照从上而下的方法判断执行顺序,可粗略认为上面的步骤优先执行。每一个执行步骤都有对应的COST,可从单步COST的高低,以及单步的估计结果集(对应ROWS/基数),来分析表的访问方式,连接顺序以及连接方式是否合理。

4、 分析表的访问方式

表的访问方式主要是两种:全表扫描(TABLE ACCESS FULL)和索引扫描(INDEX
SCAN),如果表上存在选择性很好的索引,却走了全表扫描,而且是大表的全表扫描,就说明表的访问方式可能存在问题;若大表上没有合适的索引而走了全表扫描,就需要分析能否建立索引,或者是否能选择更合适的表连接方式和连接顺序以提高效率。

5、 分析表的连接方式和连接顺序

表的连接顺序:就是以哪张表作为驱动表来连接其他表的先后访问顺序。

表的连接方式:简单来讲,就是两个表获得满足条件的数据时的连接过程。主要有三种表连接方式,嵌套循环(NESTED LOOPS)、哈希连接(HASH
JOIN)和排序-合并连接(SORT MERGE JOIN)。我们常见得是嵌套循环和哈希连接。

嵌套循环:最适用也是最简单的连接方式。类似于用两层循环处理两个游标,外层游标称作驱动表,Oracle检索驱动表的数据,一条一条的代入内层游标,查找满足WHERE条件的所有数据,因此内层游标表中可用索引的选择性越好,嵌套循环连接的性能就越高。

哈希连接:先将驱动表的数据按照条件字段以散列的方式放入内存,然后在内存中匹配满足条件的行。哈希连接需要有合适的内存,而且必须在CBO优化模式下,连接两表的WHERE条件有等号的情况下才可以使用。哈希连接在表的数据量较大,表中没有合适的索引可用时比嵌套循环的效率要高。

6、 请核心技术组协助分析  www.2cto.com

以上步骤可以协助我们初步分析SQL性能问题,如果遇到连接表太多,执行计划过于复杂,可联系核心技术组共同讨论,一起寻找更合适的SQL写法或更恰当的索引建立方法

总结两点:

1、这里看到的执行计划,只是SQL运行前可能的执行方式,实际运行时可能因为软硬件环境的不同,而有所改变,而且cost高的执行计划,不一定在实际运行起来,速度就一定差,我们平时需要结合执行计划,和实际测试的运行时间,来确定一个执行计划的好坏。

2、对于表的连接顺序,多数情况下使用的是嵌套循环,尤其是在索引可用性好的情况下,使用嵌套循环式最好的,但当ORACLE发现需要访问的数据表较大,索引的成本较高或者没有合适的索引可用时,会考虑使用哈希连接,以提高效率。排序合并连接的性能最差,但在存在排序需求,或者存在非等值连接无法使用哈希连接的情况下,排序合并的效率,也可能比哈希连接或嵌套循环要好。

附I:几种主要表连接的比较

时间: 2024-10-12 03:33:16

使用plsql执行计划进行sql调优的相关文章

Oracle SQL调优记录

目录 一.前言 二.注意点 三.Oracle执行计划 四.调优记录 @ 一.前言 本博客只记录工作中的一次oracle sql调优记录,因为数据量过多导致的查询缓慢,一方面是因为业务太过繁杂,关联了太多表.面对复杂的业务场景,确实有些情况是需要关联很多表的.当然有些情况是可以将业务实现放在Java代码里,有些情况可以不要关联很多表. 二.注意点 对于SQL调优,不要马上就说加索引什么的,加索引不一定就能解决问题的,加错索引,反而会导致查询变慢,注意加索引的同时也会影响数据库写数据的速度. 三.O

SQL调优

# 问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用 系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优 化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的 SQL语句,提高系统的可用性. 在多数情况下,Oracle

Oracle SQL 调优健康检查脚本

Oracle SQL 调优健康检查脚本 我们关注数据库系统的性能,进行数据库调优的主要工作就是进行SQL的优化.良好的数据架构设计.配合应用系统中间件和写一手漂亮的SQL,是未来系统上线后不出现致命性能问题的有力保证. 在CBO时代,一个SQL的执行计划是多样的.影响执行计划的因素也从过去RBO时代的SQL书写规则变为综合性因素.这为我们生成更加优秀执行计划提供了基础,同时也给我们进行调优带来的很多麻烦. 目前我们通常的做法,是通过AWR报告或者调试手段,发现某某SQL有问题,之后从Librar

数据库学习——SQL调优

一.SQL调优与查询优化器 数据库性能调优一般从发现.分析和解决SQL语句执行中的问题着手,这个过程统称为SQL调优(SQL tuning). 1.了解查询优化器 例如,有些查询优化器对于连接操作,一般按连接对象在FROM子句中出现的先后次序进行连接.SQL程序设计者可以利用此特点将选择性高的小表放在前面,大表放在后面,以尽快淘汰无用的中间结果,从而节省查询处理开销.又如,有些查询优化器中,凡是查询条件用OR连接的,就一概不用索引,因而只能用全表扫描,可以考虑使用UNION ALL代替OR. 2

初次使用SQL调优建议工具--SQL Tuning Advisor

在10g中,Oracle推出了自己的SQL优化辅助工具: SQL优化器(SQL Tuning Advisor :STA),它是新的DBMS_SQLTUNE包. 使用STA一定要保证优化器是CBO模式下.可是我觉得使用这样的工具,仅适合全然不懂SQL的调优的人群,不要觉得工具能解决好问题. SQL说究竟是表达的是一个业务,工具怎么可能理解业务.SQL调优还是要用autotrace,10046,10053,display_cursor这些优秀的工具做诊断.然后依据业务和所具备的oracle基础的知识

MySQL索引和SQL调优

MySQL索引 MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BTree索引,哈希索引,全文索引等等.为了避免混乱,本文将只关注于BTree索引,因为这是平常使用MySQL时主要打交道的索引. MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构.提取句子主干,就可以得到索引的本质:索引是数据结构. MySQL索引原理 索引目的 索引的目的在于提高查询效率,可以类比字典,如果要查“mysql”这个单词,

利用pl/sql执行计划评估SQL语句的性能简析

一段SQL代码写好以后,可以通过查看SQL的执行计划,初步预测该SQL在运行时的性能好坏,尤其是在发现某个SQL语句的效率较差时,我们可以通过查看执行计划,分析出该SQL代码的问题所在. 那么,作为开发人员,怎么样比较简单的利用执行计划评估SQL语句的性能呢?总结如下步骤供大家参考: 1. 打开熟悉的查看工具:PL/SQL Developer. 在PL/SQL Developer中写好一段SQL代码后,按F5,PL/SQL Developer会自动打开执行计划窗口,显示该SQL的执行计划. 2.

11g新特性-自动sql调优(Automatic SQL Tuning)

11g新特性-自动sql调优(Automatic SQL Tuning) 在Oracle 10g中,引进了自动sql调优特性.此外,ADDM也会监控捕获高负载的sql语句. 在Oracle 11g中,通过运行sql tuning advisor加强了自动sql调优功能.默认情况下是每天夜间通过自动任务的方式运行"自动sql调优". 自动sql调优的过程: 1.识别需要调优的sql语句  根据AWR中的CPU和I/O负载来识别 2.调优,生成新的sql profile 在维护窗口(mai

SQL调优常用方法

在使用DBMS时经常对系统的性能有非常高的要求:不能占用过多的系统内存和 CPU资源.要尽可能快的完成的数据库操作.要有尽可能高的系统吞吐量.如果系统开发出来不能满足要求的所有性能指标,则必须对系统进行调整,这个工作被称为调优.绝定DBMS的性能的因素有两个因素:硬件和软件.使用频率高的CPU.使用多处理器.加大内存容量.增加Cache.提高网络速度等这些都是非常有效的硬件调优方式,不过对硬件进行调优对系统性能的提高是有限的,如果有非常好的硬件条件但是如果编写的SQL质量非常差的话系统的性能并不