ORACLE中SQL查询优化研究

摘 要 数据库性能问题一直是决策者及技术人员共同关注的焦点，影响数据库性能的一个重要因素就是sql查询语句的低效率。论文首先分析了导致sql查询语句性能低下的四个常见原因以及sql调优的一般步骤，然后分别针对如何降低i/o操作、在查询语句中如何避免对查询结果的高成本操作以及在多表连接时如何提高查询效率进行了分析。 关键词 oracle；sql；优化；连接 1 引言 随着网络应用不断发展，系统性能已越来越引起决策者的重视。影响系统性能的因素很多，低效的sql语句就是其中一个不可忽视的重要原因。论文首先分析导致sql性能低下的常见原因，然后分析sql调优应遵循的一般步骤，最后从如何降低i/o、避免对查询结果的高成本操作和多表连接中如何提高sql性能进行了研究。鉴于目前oracle在数据库市场上的主导地位，论文将只针对oracle进行讨论。 2 影响sql性能的原因 影响sql性能的因素很多，如初始化参数设置不合理、导入了不准确的系统及模式统计数据从而影响优化程序(cbo)的正确判断等，这些往往和dba密切相关。纯粹从sql语句出发，笔者认为影响sql性能不外乎以下四个重要原因： (1)在大记录集上进行高成本操作，如使用了引起排序的谓词等。 (2)过多的i/o操作(含物理i/o与逻辑i/o)，最典型的就是未建立恰当的索引，导致对查询表进行全表扫描。 (3)处理了太多的无用记录，如在多表连接时过滤条件位置不当导致中间结果集包含了太多的无用记录。 (4)未充分利用数据库提供的功能，如查询的并行化处理等。 第(4)个原因处理起来相对简单。论文将针对前三个原因论述如何提高sql查询语句的性能。 3 sql优化的一般步骤 sql优化一般需经过发现问题、分析问题、提出解决措施、应用措施、测试性能几个步骤，如图1所示。“发现问题就是解决问题的一半”，因此在sql调优过程中，定位问题sql是非常重要的一步，一般可借助于oracle自带的性能优化工具如statspack、tkprof、autotrace等辅助用户进行，同时还应该重视动态性能视图如v$sql、v$mystat、v$sysstat等的研究。 图1 sql优化的一般步骤 4 sql语句的优化 4.1 优化排序操作 排序的成本十分高昂，当在查询语句中使用了引起结果集排序的谓词时，sql性能必然受到影响。 4.1.1 排序过程分析 当待排序数据集不是太大时，服务器在内存(排序区)完成排序操作，如果排序需要更多的内存空间，服务器将进行如下处理： (1) 将数据分成多个小的集合，对每一集合进行排序。 (2) 服务器向磁盘申请临时空间，将排好序的中间结果写入临时段，再对另外的集合进行排序。 (3) 在所有的集合均排好序后，服务器再将它们进行合并得到最终的结果，如果排序区尺寸太小，合并无法一次完成时，将分多次进行。 从上述分析可知，排序是一种十分昂贵的操作，它消耗大量的cpu时间和内存，触发磁盘分页和交换操作，因此只要有可能，我们就应该在sql语句中尽量避免排序操作。 4.1.2 sql中引起排序的操作 sql查询语句中引起排序的操作大致有：order by 和group by 从句；distinct修饰符；union、intersect、minus集合操作符；多表连接时的排序合并连接(sort merge join)等。 4.1.3 如何避免排序 1)建立恰当的索引 对经常进行排序和连接操作的字段建立索引。在建立索引后，当服务器向这些字段发出排序请求时，将直接引用索引而不进行排序操作；当进行等值连接查询操作时，若建立连接的字段未建立索引，服务器进行的是排序合并连接(sort merge join)，连接操作的过程如下： 对进行连接的两个或多个表分别进行全扫描； 对每一个表中的行集分别进行全排序； 合并排序结果。 如果建立连接的字段已建立索引，服务器进行嵌套循环连接(nested loop joins)，该连接方式不需要任何排序，其过程如下： 对驱动表进行全表扫描； 对返回的每一行利用连接字段值实施索引惟一扫描； 利用从索引扫描中返回的rowid值在从表中定位记录； 合并主、从表中的匹配记录。 因此，建立索引可避免多数排序操作。 2)用uniion all替换union union在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。大部分应用中是不会产生重复记录的，最常见的是过程表与历史表union 。因此，采用union all操作符替代union，因为union all操作只是简单的将两个结果合并后就返回。 4.2 优化i/o 过多的i/o操作会占用cpu时间、消耗大量内存和占用过多的栓锁，因此有必要对sql的i/o进行优化。优化i/o的最有效方式就是用索引扫描代替全表扫描。 4.2.1 应用基于函数的索引 基于函数的索引(function based index，简记为fbi)提供了索引计算列并在查询中使用这些索引的能力。fbi的实质是对查询所需中间结果进行预处理。如果一个fbi与查询语句中的内嵌函数完全匹配，cbo在生成查询计划时，将自动启用索引范围扫描(index range scan)替换全表扫描(full table scan)。考察下面的代码段并用autotrace观察创建fbi前后执行计划的变化。 select * from emp where upper(ename)=’scott’ 创建fbi前，很明显是全表扫描。 execution plan …… 1 0 table access (full) of 'employees' (cost=2 card=1 bytes=22) idle>create index emp_upper_first_name on employees(upper(first_name))； 索引已创建。 再次运行相同查询， execution plan …… 1 0 table access (by index rowid) of 'employees' (cost=1 card=1 bytes=22) 2 1 index (range scan) of 'emp_upper_first_name' (non-unique) (cost=1 card=1) 这一简单的例子充分说明了fbi在sql查询优化中的作用。fbi所用的函数可以是用户自己创建的函数，该函数越复杂，基于该函数创建fbi对sql查询性能的优化作用越明显。 4.2.2 应用物化视图和查询重写 物化视图是一个预计算结果集，其中通常包含聚集与多表连接等复杂操作。数据库自动维护物化视图，且随用户的要求进行刷新。查询重写机制就是用数据库中的替代对象(如物化视图)将用户提交的查询重写为完全不同但功能等价的查询。查询重写对用户透明，用户完全按常规编写访问数据库的查询语句，优化程序(cbo)自动决定是否对用户提交的查询进行重写。查询重写是提高查询性能的一种非常有效的方法，尤其是在数据仓库环境中针对汇总、多表连接以及其它高成本的操作方面。 下面以一个非常简单的例子来演示物化视图和查询重写在优化sql查询性能方面的作用。 select dept.deptno，dept.dname，count(*) from emp，dept where emp.deptno=dept.deptno group by dept.deptno，dept.dname /

查询计划及主要统计数据如下： 执行计划： ----------------------------------------- …… 2 1 hash join (cost=5 card=14 bytes=224) 3 2 table access (full) of 'dept' (cost=2 card=4 bytes=52) 4 2 table access (full) of 'emp' (cost=2 card=14 bytes=42) 主要统计数据： ----------------------------------------- 305 recursive calls 46 consistent gets 创建物化视图emp_dept： create materialized view emp_dept build immediate refresh on demand enable query rewrite as select dept.deptno，dept.dname，count(*) from emp，dept where emp.deptno=dept.deptno group by dept.deptno，dept.dname / 再次执行查询，执行计划及主要统计数据如下： 执行计划： ------------------------------------- …… 1 0 table access (full) of 'emp_dept' (cost=2 card=327 bytes=11445) 主要统计数据： ------------------------------------ 79 recursive calls 28 consistent gets 可见，在建立物化视图之前，首先执行两个表的全表扫描，然后进行hash连接，再进行分组排序和选择操作；而建立物化视图后，cbo自动将上述复杂操作转换为对物化视图emp_dept的全扫描，相关的统计数据也有了很大的改善，递归调用(recursive calls)由305降到79，逻辑i/o(consistent gets)由46降为28。 4.2.3 将频繁访问的小表读入cache 逻辑i/o总是快于物理i/o。如果数据库中存在被应用程序频繁访问的小表，可将这些表强行读入keep池，从而避免物理i/o的发生。 4.3 多表连接优化 最能体现查询复杂性的就是多表连接，多表连接操作往往要耗费大量的cpu时间和内存，因此多表连接查询性能优化往往是sql优化的重点与难点。 4.3.1 消除外部连接 通过消除外部连接，不仅使得到的查询更易于读取，而且性能也经常可以得到改善。一般的思路是，有以下形式的查询： select …，outer_joined_table.column from some_table，outer_joined_to_table where …=outer_joined_to_table(+) 可转换为如下形式的查询： select …，(select column from outer_ joined_to_table where …)from some_table； 4.3.2 谓词前推，优化中间结果 多表连接的性能低下多数是因为连接操作与过滤操作的次序不合理，大多数用户在编写多表连接查询时，总是先进行连接操作再应用过滤条件，这导致服务器做了太多的无用功。针对这类问题，其优化思路就是尽可能将过滤谓词前推，使不符合条件的记录提前被筛选掉，只对符合条件的少数记录进行连接处理，这样可成倍的提高sql查询效能。 如下图所示的星形模型，现要统计最近三个月进货的商品在各种销售渠道上的销售业绩。 图2 产品销售的星形模型 标准连接查询如下： select a.prod_name，sum(b.sale_quant)， sum(c.sale_quant)，sum(d.sale_quant) from product a，tele_sale b，online_sale c，store_sale d where a.prod_id=b.prod_id and a.prod_id=c.prod_id and a.prod_id=d.prod_id and a.order_date>sysdate-90 group by a.prod_id； 启用内嵌视图，且将条件a.order_date>sysdate-90前移，优化后代码如下： select a.prod_name，b.tele_sale_sum，c.online_sale_sum，d.store_sale_sum from product a， (select sum(sal_quant) tele_sale_sum from product，tele_sale where product.order_date>sysdate-90 and product.prod_id =tele_sale.prod_id) b， (select sum(sal_quant) online_sale_sum from product，tele_sale where product.order_date>sysdate-90 and product.prod_id =online_sale.prod_id) c， (select sum(sal_quant) store_sale_sum from product，store_sale where product.order_date>sysdate-90 and product.prod_id =store_sale.prod_id) d， where a.prod_id=b.prod_id and a.prod_id=c.prod_id and a.prod_id=d.prod_id； 5 结束语 sql语言在数据库应用中占有非常重要的地位，其性能的优劣直接影响着整个信息系统的可用性。论文从影响sql性能的最主要的三个方面入手，分析了如何优化sql查询的i/o、避免高成本的排序操作和优化多表连接。需要强调的一点是，理解sql语句所解决的问题比sql调优本身更重要，因此sql调优需要系统分析人员、开发人员和数据库管理员密切协作。 参考文献 [1]thomas kyte.effective oracle by design：design and build high-performance oracle application[m]，the mcgral- hill companies，inc，2003 [2]kevin loney，george koch，oracle 9i：the complete reference[m]，the mcgral-hill companies，inc，2002 [3] oracle9i sql reference release 2(9.2)[ol/m]，2002.10. http：///technology/ [4] oracle9i data warehousing guide release 2(9.2) [ol/m]，2002.03. http：///technology/ [5]alexey danchenkov，donald burleson，oracle tuning：the definitive reference[ol/m]，rampant techpress，2006. [6] oracle9i database concepts release 2(9.2) [ol/m]，2002.08. http：///technology/ [7] oracle9i supplied plsql packages and types reference release 2(9.2) [ol/m]，2002.12. http：/// technology/