文章分类 | 推荐文章 | 最新文章 | 热点文章 | 最新软件 | 精品软件 | 下载排行 | 推荐下载 | WPS | 杀毒软件
清风网络
首 页 软件下载 网络学院
QQ 电脑入门 游戏 操作系统 图形处理 办公软件 媒体动画 精文荟萃 工具软件 网络编程 程序开发 网络技术 认证考试 网站建设 文章专栏
当前位置:清风网络网络编程数据库通过分析SQL语句的执行计划优化SQL(一)
精品推荐
特别推荐
·用户登录存储过程
·SQL数据库完全使用手册
·进阶:精妙SQL语句介绍
·sql删除记录
·学习SQL语句之SQL语句大全
·数据备份失败的五个原因及解决办法
·解决SQL Server常见的七个经典问题
·SQL存储过程的概念,创建,调用,管理,删除,优点
热点TOP10
·SQL 新增/修改 表字段列的类型等
·MSSQL 通用分页存储过程的源码共享
·SQL数据库高级教程:学习 SQL Alias(别名)
·SQL数据进行排序、分组、统计10技巧
·讲述如何使用SQL CLR表值函数进行扩展
·轻松34步使你的 SQL 语句完全优化
·Discuz存在SQL注入漏洞会员可提升权限
·用SQL分布式管理对象创建数据库备份

通过分析SQL语句的执行计划优化SQL(一)

日期:2008年5月18日 作者: 查看:[大字体 中字体 小字体]


        为了实现一个查询,内核必须为每个查询定制一个查询策略,或为取出符合条件的数据生成一个执行计划(execution plan)。典型的,对于同一个查询,可能有几个执行计划都符合要求,都能得到符合条件的数据。例如,参与连接的表可以有多种不同的连接方法,这取决于连接条件和优化器采用的连接方法。为了在多个执行计划中选择最优的执行计划,优化器必须使用一些实际的指标来衡量每个执行计划使用的资源(I/0次数、CPU等),这些资源也就是我们所说的代价(cost)。如果一个执行计划使用的资源多,我们就说使用执行计划的代价大。以执行计划的代价大小作为衡量标准,优化器选择代价最小的执行计划作为真正执行该查询的执行计划,并抛弃其它的执行计划。

        在ORACLE的发展过程中,一共开发过2种类型的优化器:基于规则的优化器和基于代价的优化器。这2种优化器的不同之处关键在于:取得代价的方法与衡量代价的大小不同。现对每种优化器做一下简单的介绍:

  基于规则的优化器 -- Rule Based (Heuristic) Optimization(简称RBO):
 
  在ORACLE7之前,主要是使用基于规则的优化器。ORACLE在基于规则的优化器中采用启发式的方法(Heuristic Approach)或规则(Rules)来生成执行计划。例如,如果一个查询的where条件(where clause)包含一个谓词(predicate,其实就是一个判断条件,如”=”, “>”, ”<”等),而且该谓词上引用的列上有有效索引,那么优化器将使用索引访问这个表,而不考虑其它因素,如表中数据的多少、表中数据的易变性、索引的可选择性等。此时数据库中没有关于表与索引数据的统计性描述,如表中有多上行,每行的可选择性等。优化器也不考虑实例参数,如multi block i/o、可用排序内存的大小等,所以优化器有时就选择了次优化的计划作为真正的执行计划,导致系统性能不高。
 
  如,对于select * from emp where deptno = 10这个查询来说,如果是使用基于规则的优化器,而且deptno列上有有效的索引,则会通过deptno列上的索引来访问emp表。在绝大多数情况下,这是比较高效的,但是在一些特殊情况下,使用索引访问也有比较低效的时候,现举例说明:
        1) emp表比较小,该表的数据只存放在几个数据块中。此时使用全表扫描比使用索引访问emp表反而要好。因为表比较小,极有可能数据全在内存中,所以此时做全表扫描是最快的。而如果使用索引扫描,需要先从索引中找到符合条件记录的rowid,然后再一一根据这些rowid从emp中将数据取出来,在这种条件下,效率就会比全表扫描的效率要差一些。

        2) emp表比较大时,而且deptno = 10条件能查询出表中大部分的数据如(50%)。如该表共有4000万行数据,共放在有500000个数据块中,每个数据块为8k,则该表共有约4G,则这么多的数据不可能全放在内存中,绝大多数需要放在硬盘上。此时如果该查询通过索引查询,则是你梦魇的开始。db_file_multiblock_read_count参数的值200。如果采用全表扫描,则需要500000/db_file_multiblock_read_count=500000/200=2500次I/O。但是如果采用索引扫描,假设deptno列上的索引都已经cache到内存中,所以可以将访问索引的开销忽略不计。因为要读出4000万x 50% = 2000万数据,假设在读这2000万数据时,有99.9%的命中率,则还是需要20000次I/O,比上面的全表扫描需要的2500次多多了,所以在这种情况下,用索引扫描反而性能会差很多。在这样的情况下,用全表扫描的时间是固定的,但是用索引扫描的时间会随着选出数据的增多使查询时间相应的延长。

        上面是枯燥的假设数据,现在以具体的实例给予验证:
        环境: oracle 817 + linux + 阵列柜,表SWD_BILLDETAIL有3200多万数据;
                表的id列、cn列上都有索引

上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 下一页 



上一篇:mysql 4.1采用了新验证方法后的认证问题

下一篇:通过分析SQL语句的执行计划优化SQL(二)
相关文章:
·奇门遁甲算法分析
·光盘卫士 V1.8算法分析
·鲜为人知的Windows XP优化
·关于本地传输网络优化的问题浅析
·菜鸟必看:WinXP终极优化
·优化XP系统变量 道理在四个寓言故事中
·Flash教程:用Flash分析制作动态日历效果
相关软件:
·Windows优化精灵 V1.1
·卡耐基 心灵改造计划(上集)
·聪慧幼儿园营养分析软件v6.2
·属相分析大师 V1.0
·特别计划(Special Project Y)
·飞鹰计划(Blood Bros)
·英语句子听说大师 V2.014

特别声明:本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载,但请务必注明出处和原始作者。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站,我们表示深深的谢意。如果本站转载的文章有版权问题请联系编辑人员,我们尽快予以更正。
[打印本页] [关闭窗口] 转载请注明来源:http://www.viphot.com
| 帮助(?) | 版权声明 | 友情连接 | 关于我们 | 信息发布
Copyright 2007 www.viphot.com All Rights Reserved. 鄂ICP备05000083号Powered by:viphot