2024年4月4日发(作者：)

信息技术

2008NO.28

SCIENCE&TECHNOLOGYINFORMATION

科技资讯

优化

SQL

对

ORACLE

数据库性能的提高

710055)

徐艳赵文静

(西安建筑科技大学西安

摘要:影响ORACLE数据库性能的原因很多,论文通过优化SQL语句的几点措施,以期改善数据库的访问效率,经实际项目验证,能够明

显的提升数据库性能。

关键词:ORACLE数据库SQL优化

中图分类号:TP311.12文献标识码:A文章编号:1672-3791(2008)10(a)-0031-02

大多数情况下,系统运行缓慢不是由

于所有部件都饱和引起的,而是由于系统

中的某个部分限制了整体的性能,这部分

称为瓶颈。通常影响ORACLE数据库性能

指标的三个瓶颈主要是:CPU、内存、I/O。

数据库性能的优化主要是oracle数据库参

数的调整、磁盘I/O调整、应用程序SQL

语句分析及设计、网络性能调整等。本文

主要通过优化SQL语句来提高ORACLE数

据库的性能。

1SQL语句处理流程

如图1所示。

1.1打开游标

从上图可以看出处理SQL语句的第一

步就是要打开一个游标,事实上,一个完整

的SQL处理过程就是一个游标的生命周期。

1.2共享SQL

Oracle内存中有一个区叫SHARED_POOL,

这个区的主要作用就是将SQL语句存放在

这个区内,当客户发出一个新的SQL语句,

数据库引擎首先会到这个区查找是否有相

图1SQL语句处理流程

同的SQL,如果有,则避免了解析、分析索Bytes=1556076)

引、制定执行计划等一系列的动作。如果10TABLEACCESS(FULL)OF

没有则需要进行hardparse。'CLIENT_INFO'(Cost=31Card=17484

1.3绑定变量Bytes=1556076)

如果在SQL中指定了绑定变量,需要◆使用and关键字代替<>或!=时的

在这个阶段给SQL附上绑定变量的值。执行计划:

1.4并行处理SQL>select*fromclient_infowhere

如果SQL需要进行并行处理,在这一cl_no>1001andcl_no<1001;

阶段需要把整个SQL分割成多个并行的部norowsselected

分。ExecutionPlan

1.5执行查询0SELECTSTATEMENT

Oracle按照执行计划指定的方式执行Optimizer=CHOOSE(Cost=2Card=1

SQL,执行UPDATE和DELETE语句时,必Bytes=89)

须将行锁定,以免其他用户修改。Oracle先10FILTER

从数据库缓冲区中寻找是否存在所要的数21TABLEACCESS(BYINDEX

据块,如果存在,就直接读或修改,否则从ROWID)OF'CLIENT_INFO'(Cost=2

物理文件中读到数据库缓冲区中。Card=1Bytes=89)

1.6返回结果32INDEX(RANGESCAN)OF

对SELECT语句需要返回结果的语句,'IDX_CL_NO'(NON-UNIQUE)(Cost=1

首先看是否需要排序,需要,则排序后返回Card=1)

给用户,然后根据内存的大小不同,可以一从测试结果可以看出:

次取出一行数据,也可以一次取一组数据。<>与!=关键字会在SQL查询过程中

这时,可能要用到数据结构中的外部排序,使索引失效,造成全表扫描,所以应尽量使

并归排序等算法,所以如内存允许的话,会用and关键字来等价转换其相应的查询条

在很大程度上提高性能。件,从而提高查询速度。

2.2避免隐式转换

2SQL优化解决方案

隐式转换是最容易被开发人员忽视的

通常，一个关系数据库服务器上的SQL

一点,因为它并不影响查询结果,但它却影

进程要使用该服务器60%～90%的资源。

响了查询效率,在查询过程中,由于数据类

一般来说,数据库应用上60%的性能问题

型的不符合,造成隐式的调用to_char或

是因为运行着效率很低的SQL语句,而其

to_number函数。下面采用USER_INFO

中30%SQL语句的性能是可以被显著改进

(用户信息表)来测试这一过程,如表1所

提升的。

示。

2.1避免使用<>和!=

◆查询用户名称为101的客户信息,下

<>和!=都是不等于的意思,但在sql

面是没有隐式转换的查询:

开发过程中尽量不要使用,因为这个关键

SQL>select*fromuser_infowhere

字会造成索引失效,降低查询效率。下面

user_name='101';

是使用表client_info(客户信息表)进行测试

norowsselected

的情况,其中在cl_no(客户编号)列上建立

ExecutionPlan

了索引。

0SELECTSTATEMENT

◆使用<>或者!=查询条件时的执行

Optimizer=CHOOSE

计划:

10TABLEACCESS(BYINDEX

SQL>connabc123/passwd@MGB

ROWID)OF'USER_INFO'

Connected.

21INDEX(RANGESCAN)OF

SQL>setautotracetraceonly

'IND_USR_NAME'(NON-UNIQUE)

SQL>select*fromclient_infowhere

cl_no<>1001;

表1用户信息表

17485rowsselected.

ExecutionPlan

0SELECTSTATEMENT

Optimizer=CHOOSE(Cost=31Card=17484

科技资讯SCIENCE&TECHNOLOGYINFORMATION

31

科技资讯

2008NO.28

SCIENCE&TECHNOLOGYINFORMATION

◆查询用户名称为101的客户信息,下31488480

面是存在隐式转换的查询:Executedin11.219seconds

SQL>select*fromuser_infowhereSQL>selectcount(*)fromuser_info,

user_name=101;

cont_info;

norowsselected

COUNT(*)

ExecutionPlan

31488480

0SELECTSTATEMENT

Executedin48.407seconds

Optimizer=CHOOSE

这一结果表明,合理的表的连接顺序

10TABLEACCESS(FULL)OF

对数据库性能的提高是很有帮助的。

'USER_INFO'

2.4其他优化方案概述

从测试结果很容易看出:第二个查询

中索引失效了,这是因为ORACLE数据库

◆尽量使用Oracle已经提供的函数和

在解析过程中后台进行了隐式转换

方法,如:DECODE函数、MERGE关键字

user_name=to_char(101)造成的。

等,避免不必要的重复性开发。

2.3选择最有效率的表名顺序

◆避免使用ISNULL和ISNOT

ORACLE的解析器按照从右到左的

NULL关键字。

顺序处理FROM子句中的表名,因此

◆尽量多的使用COMMIT。

FROM子句中写在最后的表(基础表)将被

◆在程序编码中尽量避免使用“*”,

最先处理,在FROM子句中包含多个表的

因为ORACLE在解析过程中会将*解析成

情况下,必须选择记录条数最少的表作为

每个列,这个工作需要重新从数据字典中

基础表。当ORACLE处理多个表时,会运

查询获得,这就意味着解析过程将消耗过

用排序及合并的方式连接首先,扫描第一

多的时间。

张表(FROM子句中最后的那个表)并对记

◆避免索引列上的计算,尽量用>=代

录进行排序,然后扫描第二张表(FROM

替>,以减少扫描记录的个数。

子句中最后第二个表),最后将所有从第

◆尽量将SQL语句封装在PROCE-

二张表中检索出的记录与第一个表中合

DURE中,这样可以略去语义分析等大部

适记录进行合并。下面是对这一理论的

分重复性的工作。

验证,其中用户信息表user_info有999条

◆合理利用函数索引以避免全表扫

数据,合同信息表cont_info有32000条数

描,加快查询速度。

据。

◆对于不同规模的表,正确选择表的

SQL>selectcount(*)fromcont_info,

连接方式。

user_info;

除此之外,还有很多SQL优化方案,由

COUNT(*)

于篇幅等问题,不在一一测试验证。

(上接30页)

基于数值模拟结果,随着开挖步数的

下而产生的墙外侧位移。通过对以上计算增加,基坑支护外侧土体得位移量逐渐增

结果分析可以得出基坑开挖过程土体移动加,最大沉降量发生在第九步,沉降值大小

机理。由于基坑开挖垂直卸荷作用改变坑为28.7mm,满足工程需要。此外,随着基

底土体原始应力状态,基坑底部土体在卸坑开挖步数的增加地表位移的沉降量也在

荷后产生垂直弹性隆起。基坑周围土体向逐步增大,距离基坑较远处发生的地表沉

下移动,以补充由于基底隆起而损失的土降值较基坑附近地表沉降值要大

体。通过以上的计算可以得出结论,如果基于数值模拟结果,基坑开挖过程是

使用62m的地下连续墙体和五层钢管支撑基坑开挖面上卸荷的过程,由于卸荷而引

加四层钢筋混凝土梁的支撑体系,基坑在起坑底土体产生以向上为主的位移,同时

开挖过程中和开挖结束后,都还处于十分也引起围护墙体在两侧压力差的作用下而

稳定的状态,基坑的周围土体的地表最大产生的墙外侧位移。基坑在开挖过程中和

沉降量小于开挖深度的0.1%,围护墙体最开挖结束后,都还处于十分稳定的状态,基

大水平位移为41.2mm,同样满足小于开挖坑的周围土体的地表最大沉降量小于开挖

深度的0.14%。深度的0.1%,围护墙体最大水平位移为

41.2mm,同样满足小于开挖深度的0.14%。

3结语

本文结合上海市宜山路实际基坑工

参考文献

程,利用大型有限元分析软件FLAC-3D对[1]沈细中.深基坑工程基本过程数值模拟

基坑开挖过程土体的变形影响进行的数值及实时优化研究[J].武汉大学,2004.

模拟研究。分析研究结果表明:[2]应捷.考虑土—结构相互作用的深基坑

利用大型有限差分数值模拟软件进行弹性地基有限元分析[J].西安建筑科技

超深基坑开挖的数值模拟研究是切实可行大学,2003.

的,模拟分析得到的数值结果满足工程以[3]吴钰骅.软土深基坑工程流变及共同变

及理论上的基本要求,与实际工程测量结形性状研究[J].浙江大学,2004.

果大致吻合。[4]钱家欢,殷宗泽.土工原理与计算(第二

32

科技资讯SCIENCE&TECHNOLOGYINFORMATION

信息技术

3结语

SQL的优化与调整是花费最少且效果

最明显的提升数据库性能的方法,但同时

也是非常重要和复杂的内容。数据库性能

的提升不光是数据库管理员的职责,它需

要开发人员的配合与支持,并采用正确的

方法,才能最终达到优化的目的。

参考文献

[1]冯春培,盖国强,等.ORACLE数据库

DBA专题技术精粹[M].冶金工业出版

社,2004.

[2]DennisShasha,PhilippeBonnet.数据

库性能调优原理与技术[M].电子工业

出版社,2004.

版)[M].北京:中国水利水电出版社,

1994.

[5]龚晓南.土的塑性力学(第二版)[M].杭州:

浙江大学出版社,1999.

[6]TAI,D,SMALL,isofpileraft

systemsinlayeredsoils[J].IntJnlNum

AnalMechsInGeomechs,1996(20).