收藏 分销(赏)

ORACLE中SQL查询.docx

上传人:w****g 文档编号:3843956 上传时间:2024-07-22 格式:DOCX 页数:14 大小:17.72KB 下载积分:8 金币
下载 相关 举报
ORACLE中SQL查询.docx_第1页
第1页 / 共14页
ORACLE中SQL查询.docx_第2页
第2页 / 共14页


点击查看更多>>
资源描述
ORACLE中SQL查询   摘要数据库性能问题一直是决策者及技术人员共同关注的焦点,影响数据库性能的一个重要因素就是SQL查询语句的低效率。论文首先分析了导致SQL查询语句性能低下的四个常见原因以及SQL调优的一般步骤,然后分别针对如何降低I/O操作、在查询语句中如何避免对查询结果的高成本操作以及在多表连接时如何提高查询效率进行了分析。   关键词ORACLE;SQL;优化;连接   1引言   随着网络应用不断发展,系统性能已越来越引起决策者的重视。影响系统性能的因素很多,低效的SQL语句就是其中一个不可忽视的重要原因。论文首先分析导致SQL性能低下的常见原因,然后分析SQL调优应遵循的一般步骤,最后从如何降低I/O、避免对查询结果的高成本操作和多表连接中如何提高SQL性能进行了研究。鉴于目前ORACLE在数据库市场上的主导地位,论文将只针对ORACLE进行讨论。   2影响SQL性能的原因   影响SQL性能的因素很多,如初始化参数设置不合理、导入了不准确的系统及模式统计数据从而影响优化程序的正确判断等,这些往往和DBA密切相关。纯粹从SQL语句出发,笔者认为影响SQL性能不外乎以下四个重要原因:   在大记录集上进行高成本操作,如使用了引起排序的谓词等。   过多的I/O操作,最典型的就是未建立恰当的索引,导致对查询表进行全表扫描。   处理了太多的无用记录,如在多表连接时过滤条件位置不当导致中间结果集包含了太多的无用记录。   未充分利用数据库提供的功能,如查询的并行化处理等。   第个原因处理起来相对简单。论文将针对前三个原因论述如何提高SQL查询语句的性能。   3SQL优化的一般步骤   SQL优化一般需经过发现问题、分析问题、提出解决措施、应用措施、测试性能几个步骤,如图1所示。“发现问题就是解决问题的一半”,因此在SQL调优过程中,定位问题SQL是非常重要的一步,一般可借助于ORACLE自带的性能优化工具如STATSPACK、TKPROF、AUTOTRACE等辅助用户进行,同时还应该重视动态性能视图如V$SQL、V$MYSTAT、V$SYSSTAT等的研究。   图1SQL优化的一般步骤   4SQL语句的优化优化排序操作   排序的成本十分高昂,当在查询语句中使用了引起结果集排序的谓词时,SQL性能必然受到影响。   排序过程分析   当待排序数据集不是太大时,服务器在内存完成排序操作,如果排序需要更多的内存空间,服务器将进行如下处理:   将数据分成多个小的集合,对每一集合进行排序。   服务器向磁盘申请临时空间,将排好序的中间结果写入临时段,再对另外的集合进行排序。   在所有的集合均排好序后,服务器再将它们进行合并得到最终的结果,如果排序区尺寸太小,合并无法一次完成时,将分多次进行。   从上述分析可知,排序是一种十分昂贵的操作,它消耗大量的CPU时间和内存,触发磁盘分页和交换操作,因此只要有可能,我们就应该在SQL语句中尽量避免排序操作。   中引起排序的操作   SQL查询语句中引起排序的操作大致有:ORDERBY和GROUPBY从句;DISTINCT修饰符;UNION、INTERSECT、MINUS集合操作符;多表连接时的排序合并连接等。   如何避免排序   1)建立恰当的索引   对经常进行排序和连接操作的字段建立索引。在建立索引后,当服务器向这些字段发出排序请求时,将直接引用索引而不进行排序操作;当进行等值连接查询操作时,若建立连接的字段未建立索引,服务器进行的是排序合并连接,连接操作的过程如下:   对进行连接的两个或多个表分别进行全扫描;   对每一个表中的行集分别进行全排序;   合并排序结果。   如果建立连接的字段已建立索引,服务器进行嵌套循环连接,该连接方式不需要任何排序,其过程如下:   对驱动表进行全表扫描;   对返回的每一行利用连接字段值实施索引惟一扫描;   利用从索引扫描中返回的ROWID值在从表中定位记录;   合并主、从表中的匹配记录。   因此,建立索引可避免多数排序操作。   2)用UNIIONALL替换UNION   UNION在进行表链接后会筛选掉重复的记录,所以在表链接后会对所产生的结果集进行排序运算,删除重复的记录再返回结果。大部分应用中是不会产生重复记录的,最常见的是过程表与历史表UNION。因此,采用UNIONALL操作符替代UNION,因为UNIONALL操作只是简单的将两个结果合并后就返回。   优化I/O   过多的I/O操作会占用CPU时间、消耗大量内存和占用过多的栓锁,因此有必要对SQL的I/O进行优化。优化I/O的最有效方式就是用索引扫描代替全表扫描。   应用基于函数的索引   基于函数的索引提供了索引计算列并在查询中使用这些索引的能力。FBI的实质是对查询所需中间结果进行预处理。如果一个FBI与查询语句中的内嵌函数完全匹配,CBO在生成查询计划时,将自动启用索引范围扫描替换全表扫描。考察下面的代码段并用AUTOTRACE观察创建FBI前后执行计划的变化。   select*fromempwhereupper=’SCOTT’   创建FBI前,很明显是全表扫描。   ExecutionPlan   ……   10brACCESSOF''''EMPLOYEES''''   idle>CREATEINDEXEMP_UPPER_FIRST_NAMEONEMPLOYEES);   索引已创建。   再次运行相同查询,   ExecutionPlan   ……   10brACCESSOF''''EMPLOYEES''''   21INDEXOF''''EMP_UPPER_FIRST_NAME''''   这一简单的例子充分说明了FBI在SQL查询优化中的作用。FBI所用的函数可以是用户自己创建的函数,该函数越复杂,基于该函数创建FBI对SQL查询性能的优化作用越明显。   应用物化视图和查询重写   物化视图是一个预计算结果集,其中通常包含聚集与多表连接等复杂操作。数据库自动维护物化视图,且随用户的要求进行刷新。查询重写机制就是用数据库中的替代对象将用户提交的查询重写为完全不同但功能等价的查询。查询重写对用户透明,用户完全按常规编写访问数据库的查询语句,优化程序自动决定是否对用户提交的查询进行重写。查询重写是提高查询性能的一种非常有效的方法,尤其是在数据仓库环境中针对汇总、多表连接以及其它高成本的操作方面。   下面以一个非常简单的例子来演示物化视图和查询重写在优化SQL查询性能方面的作用。   ,,count   fromemp,dept   =   ,   查询计划及主要统计数据如下:   执行计划:   -----------------------------------------   ……   21HASHJOIN   32brACCESSOF''''DEPT''''   42brACCESSOF''''EMP''''   主要统计数据:   -----------------------------------------   305recursivecalls   46consistentgets   创建物化视图EMP_DEPT:   creatematerializedviewemp_deptbuildimmediate   refreshondemand   enablequeryrewrite   as   ,,count   fromemp,dept   =   ,   /   再次执行查询,执行计划及主要统计数据如下:   执行计划:   -------------------------------------   ……   10brACCESSOF''''EMP_DEPT''''   主要统计数据:   ------------------------------------   79recursivecalls   28consistentgets   可见,在建立物化视图之前,首先执行两个表的全表扫描,然后进行HASH连接,再进行分组排序和选择操作;而建立物化视图后,CBO自动将上述复杂操作转换为对物化视图EMP_DEPT的全扫描,相关的统计数据也有了很大的改善,递归调用由305降到79,逻辑I/O由46降为28。   将频繁访问的小表读入CACHE   逻辑I/O总是快于物理I/O。如果数据库中存在被应用程序频繁访问的小表,可将这些表强行读入KEEP池,从而避免物理I/O的发生。   多表连接优化   最能体现查询复杂性的就是多表连接,多表连接操作往往要耗费大量的CPU时间和内存,因此多表连接查询性能优化往往是SQL优化的重点与难点。   消除外部连接   通过消除外部连接,不仅使得到的查询更易于读取,而且性能也经常可以得到改善。一般的思路是,有以下形式的查询:   SELECT…,OUTER_JOINED_   FROMSOME_br,OUTER_JOINED_TO_br   WHERE…=OUTER_JOINED_TO_br   可转换为如下形式的查询:   SELECT…,FROMSOME_br;   谓词前推,优化中间结果   多表连接的性能低下多数是因为连接操作与过滤操作的次序不合理,大多数用户在编写多表连接查询时,总是先进行连接操作再应用过滤条件,这导致服务器做了太多的无用功。针对这类问题,其优化思路就是尽可能将过滤谓词前推,使不符合条件的记录提前被筛选掉,只对符合条件的少数记录进行连接处理,这样可成倍的提高SQL查询效能。   如下图所示的星形模型,现要统计最近三个月进货的商品在各种销售渠道上的销售业绩。   图2产品销售的星形模型   标准连接查询如下:   _name,sum,   sum,sum   Fromproducta,tele_saleb,online_salec,store_saled   _id=__id=_id   _id=__date>sysdate-90   _id;   启用内嵌视图,且将条件_date>sysdate-90前移,优化后代码如下:   _name,_sale_sum,_sale_sum,_sale_sumFromproducta,   tele_sale_sumfromproduct,tele_sale   _date>_id=tele__id)b,   online_sale_sum   fromproduct,tele_sale   _date>_id=online__id)c,   store_sale_sum   fromproduct,store_sale   _date>_id=store__id)d,   _id=_idand   _id=__id=_id;   5结束语   SQL语言在数据库应用中占有非常重要的地位,其性能的优劣直接影响着整个信息系统的可用性。论文从影响SQL性能的最主要的三个方面入手,分析了如何优化SQL查询的I/O、避免高成本的排序操作和优化多表连接。需要强调的一点是,理解SQL语句所解决的问题比SQL调优本身更重要,因此SQL调优需要系统分析人员、开发人员和数据库管理员密切协作。   参考文献   [1]:DesignandBuildHigh-performanceOracleApplication[M],TheMcGral-HillCompanies,Inc,2003   [2]KevinLoney,GeorgeKoch,Oracle9i:TheCompleteReference[M],TheMcGral-HillCompanies,Inc,2002   [3]Oracle9iSQLReferencerelease2[OL/M],:///technology/   [4]Oracle9iDataWarehousingGuiderelease2[OL/M],:///technology/   [5]AlexeyDanchenkov,DonaldBurleson,OracleTuning:TheDefinitiveReference[OL/M],RampantTechpress,2006.   [6]Oracle9iDatabaseConceptsrelease2[OL/M],:///technology/   [7]Oracle9isuppliedplsqlpackagesandtypesreferencerelease2[OL/M],:///technology/ORACLE中SQL查询
展开阅读全文

开通  VIP会员、SVIP会员  优惠大
下载10份以上建议开通VIP会员
下载20份以上建议开通SVIP会员


开通VIP      成为共赢上传

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        抽奖活动

©2010-2026 宁波自信网络信息技术有限公司  版权所有

客服电话:0574-28810668  投诉电话:18658249818

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :微信公众号    抖音    微博    LOFTER 

客服