SQL语句优化(转载)

同等、操作符优化

1、IN 操作符

于是IN写出来的SQL的长处是较轻写及清晰易懂,这正如可现代软件开发的作风。但是之所以IN的SQL性能总是比低之,从Oracle执行之步调来分析因此IN的SQL与不用IN的SQL有以下分别:

ORACLE试图将那个更换成为多单说明底连日,如果换不成事则优先实行IN里面的子查询,再查询外层的表记录,如果换成则一直以多只说明底连接方式查询。由此可见用IN的SQL至少多矣一个换的过程。一般的SQL都足以转换成,但对富含分组统计等地方的SQL就无克转换了。

推介方案:在工作密集的SQL当中尽量不应用IN操作符,用EXISTS 方案代替。

2、NOT IN操作符

这个操作是强列不推荐下的,因为她不可知应用表的目。

推荐方案:所以NOT EXISTS 方案代替

3、IS NULL 或IS NOT NULL操作(判断字段是否为空)

认清字段是否为空一般是免见面采用索引的,因为索引是不索引空值的。

推介方案:用外相同功能的操作运算代替,如:a is not null 改吗
a>0
或a>’’等。不容许字段为空,而用一个缺乏省值代替空值,如申请被状态字段不允为空,缺省吗申请。

4、> < 操作符(大于或小于操作符)

逾或低于操作符一般景象下是毫不调整之,因为她发目录就会见用索引查找,但有些情况下足针对它进行优化,如一个发明来100万笔录,一个数值类字段A,30万记下的A=0,30万记下之A=1,39万记录之A=2,1万笔录的A=3。那么执行A>2和A>=3的功用就是闹深非常的区分了,因为A>2时ORACLE会先找有呢2底记录索引再开展比,而A>=3时ORACLE则一直找到=3的记录索引。

5、LIKE操作符

LIKE操作符可以应用通配符查询,里面的通配符组合或达到几乎是随便的询问,但是若因此得不得了则会时有发生性能及之问题,如LIKE
‘%5400%’ 这种查询不见面引用索引,而LIKE ‘X5400%’则会引用范围索引。

一个实在例子:用YW_YHJBQK表中营业编号后面的家标识号可来询问营业编号
YY_BH LIKE ‘%5400%’ 这个原则会出全表扫描,如果改动化YY_BH LIKE
’X5400%’ OR YY_BH LIKE ’B5400%’
则会动用YY_BH的目录进行有限单限之询问,性能肯定大大提高。

6、UNION操作符

UNION以展开表链接后会筛选掉还的笔录,所以于表链接后会对所出的结果集进行排序运算,删除重复的记录还返回结果。实际大部分采取中凡勿会见时有发生更的记录,最广泛的是过程表与史表UNION。如:
select * from gc_dfys
union
select * from ls_jg_dfys
此SQL在运转时先取出两个说明底结果,再就此排序空间进行排序删除重复的笔录,最后回到结果集,如果表数据量大的言辞也许会见招用磁盘进行排序。

推介方案:以UNION ALL操作符替代UNION,因为UNION
ALL操作只是略的拿鲜独结果合并后虽回。

select * from gc_dfys
union all
select * from ls_jg_dfys

其次、SQL书写的熏陶

1、同一功能雷同性质差写法SQL的影响。

假定一个SQL在A程序员写的吧  Select * from zl_yhjbqk

B程序员写的吧 Select * from dlyx.zl_yhjbqk(带表所有者的前缀)

C程序员写的也 Select * from DLYX.ZLYHJBQK(大写表名)

D程序员写的也罢 Select *  from DLYX.ZLYHJBQK(中间多矣空格)

以上四独SQL在ORACLE分析整理后有的结果及实施的时空是相同的,但是打ORACLE共享内存SGA的规律,可以得出ORACLE对每个SQL
都见面对该展开同样次于分析,并且占共享内存,如果以SQL的字符串及格式写得完全相同,则ORACLE只会分析一次,共享内存也仅仅见面留给一软的解析结果,这不只可以减去分析SQL的年华,而且得削减共享内存重复的音,ORACLE也可以确切统计SQL的施行效率。

2、WHERE后面的条件顺序影响

WHERE子句子后的尺度顺序对大数额量表的询问会发生直接的影响。如:
Select * from zl_yhjbqk where dy_dj = ‘1KV以下’ and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = ‘1KV以下’

以上两只SQL中dy_dj(电压级)及xh_bz(销户标志)两单字段都并未开展索引,所以实行之时光都是全表扫描,第一长达SQL的dy_dj

‘1KV以下’条件在笔录集内比率为99%,而xh_bz=1的比值只吧0.5%,在进行第一漫长SQL的时节99%漫漫记下都开展dy_dj及xh_bz的较,而于展开次条SQL的当儿0.5%久记下还开展dy_dj及xh_bz的比,以这可以得出第二长长的SQL的CPU占用率明显较第一长条小。

3、查询表顺序的熏陶

当FROM后面的表中的列表顺序会指向SQL执行性影响,在并未索引及ORACLE没有对表进行统计分析的情事下,ORACLE会按表出现的顺序进行链接,由此可见表底相继不对时见面有十分耗服物器资源的数额交叉。(注:如果对表进行了统计分析,ORACLE会自动进取小表的链接,再展开大表的链接)

其三、SQL语句索引的行使

1、操作符优化(同上)

2、对规范字段的有的优化

以函数处理的字段不能够运用索引,如:

substr(hbs_bh,1,4)=’5400’,优化处理:hbs_bh like ‘5400%’

trunc(sk_rq)=trunc(sysdate), 优化处理:sk_rq>=trunc(sysdate) and
sk_rq<trunc(sysdate+1)

进展了显式或隐式的演算的字段不能够展开索引,如:ss_df+20>50,优化处理:ss_df>30

‘X’ || hbs_bh>’X5400021452’,优化处理:hbs_bh>’5400021542’

sk_rq+5=sysdate,优化处理:sk_rq=sysdate-5

hbs_bh=5401002554,优化处理:hbs_bh=’ 5401002554’,注:此标准对hbs_bh
进行隐式的to_number转换,因为hbs_bh字段是字符型。

规则外连了大半独本表的字段运算时莫克拓展索引,如:ys_df>cx_df,无法进行优化
qc_bh || kh_bh=’5400250000’,优化处理:qc_bh=’5400’ and
kh_bh=’250000’

四、其他

ORACLE的提示作用是比大之力量,也是比较复杂的下,并且提示只是被ORACLE执行之一个提议,有时使是因为成本方面的设想ORACLE也或不会见按提示进行。根据实施以,一般不建议开发人员应用ORACLE提示,因为各个数据库与服务器性能情况不一样,很可能一个地方性能提升了,但另外一个地方倒降低了,ORACLE在SQL执行分析者都较成熟,如果条分缕析执行之路子不对准第一应以数据库结构(主要是索引)、服务器时性(共享内存、磁盘文件碎片)、数据库对象(表、索引)统计信息是否科学就几乎面分析。

 

相关文章