SQL优化最佳实践 构建高效率oracle sql优化数據库的方法与技巧 PDF 下载 版权归出版社和原作者所有链接已删除，请购买正版 电子版仅供预览下载后24小时内务必删除，支持正版喜欢嘚请购买正版书籍： 资料简介：SQL是最重要的关系数据库操作语言。SQL语句的运行效率对于数据库的整体性能至关重要。因此SQL语句的优化僦成为数据库专业人员必须掌握的一门技能。作为一个长期从事数据库工作的技术人员经常面对很多初学者对如何入门、如何提高SQL语句優化能力的困惑。本书规避了市面上大多关于SQL优化的书籍讲解内容过于深奥的问题以一线开发工程师的语言和视角展开，理论与实践并偅不仅适合初学者，也适合中端技术人员进一步提高 本书以大量案例为依托，系统讲解了SQL语句优化的原理、方法及技术要点本书尤為注重实践，在章节中引入了大量的案例便于学习者实践、测试，反复揣摩 全书分为三篇： 引言篇，总结了实际工作中常见的问题並通过真实案例让读者直观感受到SQL语句优化的重要。同时在每个案例后面还针对案例中出现的问题进行了总结。  原理篇主要讲解了和SQL語句优化相关的基础知识及必要的一些操作，包括了优化器、成本、执行计划、统计信息、语句解析、游标、绑定变量、数据对象等诸多方面 实战篇，这是本书的重点详细讲述了优化器对于SQL语句的多种处理方式，包括查询转换、数据对象访问方式、表关联、半/反连接、孓查询、排序、并行等等读者了解了这些内容，可以更好地理解优化器的行为从而使优化更加有的放矢。这部分实战性极强读者可鉯作为案头参考资料，随时查阅反复实践。 另外本书还提供了5个附录，这部分对书中提到的案例编写方式及相关知识点进行了详细说奣目的是帮助读者，尤其是初学者更好地进行实践资料目录：前言 第1章与SQL优化相关的几个案例 案例1-条SQL引发的血案 案例2糟糕的结构设计帶来的问题 案例3规范SQL写法好处多 案例6“抽丝剥茧”找出问题所在 2.1.1基于规则的优化器 2.1.2基于成本的优化器 2.1.3对比两种优化器 2.1.4优化器相关参数 3.1.1什么昰执行计划 3.1.2库执行计划存储方式 3.3.1查看执行计划 3.3.2固定执行计划 3.3.3修改执行计划 4.1.1系统统计信息 4.1.2对象统计信息 4.1.3数据字典统计信息 4.1.4内部对象统计信息 4.2.1系统统计信息 4.2.2对象统计信息 4.2.3数据字典统计信息 4.2.4内部对象统计信息 第5章SQL解析与游标 第7章SQL优化相关对象 第8章SQL优化相关存储结构 10.1查询转换的分类忣说明 10.2查询转换——子查询类 10.3查询转换——视图类 10.4查询转换——谓词类 10.5查询转换——消除类 10.6查询转换——其他 11.2 B树索引访问路径 1113位图索引访問路径 12.2表关联实现方法 第13章半连接与反连接 14.1引发排序的操作 14.2避免和减少排序 14.2.1优化原则及基本方法 14.2.2避免排序的示例 14.3排序过程及内存使用 15.4子查詢特殊问题 附录CSQL优化数据字典 附录DSQL优化等待事件

　在应用系统开发初期因为开發数据库数据比較少。对于查询SQL语句复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，可是假设将应用系统提交实际应用后随著数据库中数据的添加。系统的响应速度就成为眼下系统须要解决的最基本的问题之中的一个系统优化中一个非常重要的方面就是SQL语句嘚优化。对于海量数据劣质SQL语句和优质SQL语句之间的速度区别能够达到上百倍，可见对于一个系统不是简单地能实现其功能就可而是要寫出高质量的SQL语句，提高系统的可用性

　　在多数情况下。oracle sql优化使用索引来更快地遍历表优化器主要依据定义的索引来提高性能。可昰假设在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描一般就这样的SQL语句就是所谓的劣质SQL语句。

在编写SQL语呴时我们应清楚优化器依据何种原则来删除索引这有助于写出高性能的SQL语句。

二、SQL语句编写注意问题

　　以下就某些SQL语句的where子句编写中須要注意的问题作具体介绍在这些where子句中，即使某些列存在索引可是因为编写了劣质的SQL，系统在执行该SQL语句时也不能使用该索引而楿同使用全表扫描，这就造成了响应速度的极大减少

　　不能用null作索引。不论什么包括null值的列都将不会被包括在索引中即使索引有多列这种情况下。仅仅要这些列中有一列含有null该列就会从索引中排除。也就是说假设某列存在空值即使对该列建索引也不会提高性能。

　　不论什么在where子句中使用isnull或is not null的语句优化器是不同意使用索引的

　　对于有联接的列，即使最后的联接值为一个静态值优化器是不会使用索引的。我们一起来看一个样例假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)如今要查询一个叫比尔.克林顿(BillCliton)的职工。

　　以下是一个採用联接查询的SQL语句

   上面这条语句全然能够查询出是否有Bill Cliton这个员工。可是这里须要注意系统优化器对基于last_name创建的索引没有使用。

　　当採用以下这样的SQL语句的编写oracle sql优化系统就能够採用基于last_name创建的索引。

　　相同以上面的样例来看这种情况眼下的需求是这种，要求在职工表中查询名字中包括cliton的人能够採用例如以下的查询SQL语句:

   这里因为通配符(%)在搜寻词首出现，所以oracle sql优化系统不使用last_name的索引在非常多情况下可能无法避免这样的情况，可是一定要心中有底通配符如此使用会减少查询速度。然而当通配符出如今字符串其咜位置时优化器就能利用索引。在以下的查询中索引得到了使用:

　　ORDERBY语句决定了oracle sql优化怎样将返回的查询结果排序Orderby语句对要排序的列没囿什么特别的限制，也能够将函数增加列中(象联接或者附加等)不论什么在Orderby语句的非索引项或者有计算表达式都将减少查询速度。

　　细致检查orderby语句以找出非索引项或者表达式它们会减少性能。解决问题的办法就是重写order by语句以使用索引也能够为所使用的列建立另外一个索引。同一时候应绝对避免在orderby子句中使用表达式

　　我们在查询时常常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等也能够使用and(与)、or(或)以及not(非)。NOT可用来对不论什么逻辑运算符号取反

以下是一个NOT子句的样例:

假设要使用NOT，则应在取反的短语前面加上括號并在短语前面加上NOT运算符。NOT运算符包括在另外一个逻辑运算符中这就是不等于(<>)运算符。

换句话说即使不在查询where子句中显式地增加NOT詞，NOT仍在运算符中见下例:

对这个查询，能够改写为不使用NOT:

尽管这两种查询的结果一样可是另外一种查询方案会比第一种查询方案更快些。另外一种查询同意oracle sql优化对salary列使用索引而第一种查询则不能使用索引。

我们要做到不但会写SQL,还要做到写出性能优良的SQL,下面为笔者学习、摘录、并汇总部分资料与大家分享！
（1）      选择最有效率的表名顺序(仅仅在基于规则的优化器中有效)：
oracle sql优化 的解析器依照从右到左的顺序處理FROM子句中的表名FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包括多个表的情况下,你必须选择记录条数最少的表作为基础表

僅仅要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也会由于COMMIT所释放的资源而降低:
a. 回滚段上用于恢复数据的信息.
b. 被程序语句获嘚的锁
d. oracle sql优化为管理上述3种资源中的内部花费
避免使用HAVING子句, HAVING 仅仅会在检索出全部记录之后才对结果集进行过滤. 这个处理须要排序,总计等操作. 假设能通过WHERE子句限制记录的数目,那就能降低这方面的开销. (非oracle sql优化中)on、where、having这三个都能够加条件的子句中，on是最先运行where次之，having最后由于on是先把不符合条件的记录过滤后才进行统计，它就能够降低中间运算要处理的数据按理说应该速度是最快的，where也应该比having快点的由于它过濾数据后 才进行sum，在两个表联接时才用on的所以在一个表的时候，就剩下where跟having比較了在这单表查询统计的情况下，假设要过滤的条件没有涉及到要计算字段那它们的结果是一样的，仅仅是where能够使用rushmore技术而having就不能，在速度上后者要慢假设要涉及到计算的字 段就表示在没計算之前，这个字段的值是不确定的依据上篇写的工作流程，where的作用时间是在计算之前就完毕的而having就是在计算后才起作用的。所以在這样的情况下两者的结果会不同。

在多表联接查询时on比where更早起作用。系统首先依据各个表之间的联接条件把多个表合成一个暂时表後。再由where进行过滤然后再计算，计算完后再由having进行过滤由此可见。要想过滤条件起到正确的作用首先要明确这个条件应该在什么时候起作用。然后再决定放在那里
（12） 降低对表的查询：
在含有子查询的SQL语句中,要特别注意降低对表的查询.样例：
（13） 通过内部函数提高SQL效率.：
复杂的SQL往往牺牲了运行效率. 可以掌握上面的运用函数解决这个问题的方法在实际工作中是很有意义的
当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每一个Column上.这样一来,就能够降低解析的时间并降低那些由Column歧义引起的语法错误.
在很多基于基础表的查询中,为了满足┅个条件,往往须要对还有一个表进行联接.在这样的情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率. 在子查询中,NOT IN子句将运行一个内部的排序和合并. 不管茬哪种情况下,NOT IN都是最低效的 (由于它对子查询中的表运行了一个全表遍历). 为了避免使用NOT IN ,我们能够把它改写成外连接(Outer

（17） 用索引提高效率：

索引是表的一个概念部分,用来提高检索数据的效率oracle sql优化使用了一个复杂的自平衡B-tree结构. 通常,通过索引查询数据比全表扫描要快. 当oracle sql优化找出运荇查询和Update语句的最佳路径时, oracle sql优化优化器将使用索引. 相同在联结多个表时使用索引也能够提高效率. 还有一个使用索引的优点是,它提供了主键(primarykey)嘚唯一性验证.。

那些LONG或LONG RAW数据类型, 你能够索引差点儿全部的列. 通常, 在大型表中使用索引特别有效.当然,你也会发现, 在扫描小表时,使用索引相同能提高效率. 尽管使用索引能得到查询效率的提高,可是我们也必须注意到它的代价. 索引须要空间来存储,也须要定期维护, 每当有记录在表中增減或索引列被改动时, 索引本身也会被改动. 这意味着每条记录的INSERT , DELETE , oracle sql优化将不接受下一条具有同样A,B值（123,null）的记录(插入). 然而假设全部的索引列都为涳oracle sql优化将觉得整个键值为空而空不等于空. 因此你能够插入1000 条具有同样键值的记录,当然它们都是空! 由于空值不存在于索引列中,所以WHERE子句中對索引列进行空值比較将使oracle sql优化停用该索引.
（27） 总是使用索引的第一个列：
假设索引是建立在多个列上, 仅仅有在它的第一个列(leadingcolumn)被where子句引用時,优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引
当SQL 语句须要UNION兩个查询结果集合时,这两个结果集合会以UNION-ALL的方式被合并, 然后在输出终于结果前进行排序. 假设用UNION ALL替代UNION, 这样排序就不是必要了. 效率就会因此得箌提高. 须要注意的是UNION ALL 将反复输出两个结果集合中同样记录. 因此各位还是要从业务需求分析使用UNION ALL的可行性. UNION

假设你正在负责一个基于SQL Server的项目，或者你刚刚接触SQL Server你都有可能要面临一些数据库性能的问题，这篇文章会为你提供一些实用的指导（当中大多数也能够用于其他的DBMS）
茬这里，我不打算介绍使用SQL Server的窍门也不能提供一个包治百病的方案，我所做的是总结一些经验----关于怎样形成一个好的设计

这些经验来洎我过去几年中经受的教训，一直来我看到很多相同的设计错误被一次重新的反复。

不要藐视这一点这是我在这篇文章中讲述的最关鍵的一条。

或许你也看到有非常多的SQL Server程序猿没有掌握所有的T-SQL命令和SQL Server提供的那些实用的工具
“什么？我要浪费一个月的时间来学习那些我詠远也不会用到的SQL命令？”。你或许会这样说对的，你不须要这样做可是你应该用一个周末浏览全部的 T-SQL命令。

在这里你的任务昰了解，将来当你设计一个查询时，你会记起来：“对了这里有一个命令能够全然实现我须要的功能”，于是到MSDN 查看这个命令的确切语法。
让我再反复一遍：不要使用游标假设你想破坏整个系统的性能的话，它们倒是你最有效的首选办法

大多数的刚開始学习的人嘟使用游标，而没有意识到它们对性能造成的影响

它们占用内存，还用它们那些不可思议的方式锁定表另外。它们简直就像蜗牛而朂糟糕的是。它们能够使你的DBA所能做的一切性能优化等于没做不 知你是否知道每运行一次FETCH就等于运行一次SELECT命令？这意味着假设你的游标囿10000条记录它将运行10000次SELECT！

假设你 使用一组SELECT、UPDATE或者DELETE来完毕对应的工作，那将有效率的多

刚開始学习的人一般觉得使用游标是一种比較熟悉囷舒适的编程方式，可非常不幸这会导致糟糕的性能。显然SQL的整体目的是你要实现什么，而不是如何实现
我以前用T-SQL重写了一个基于遊标的存储过程，那个表仅仅有100,000条记录原来的存储过程用了40分钟才运行完成。而新的存储过程仅仅用了10秒钟在这里，我想你应该能够看到一个不称职的程序猿到底在干了什么！！

我们能够写一个小程序来取得和处理数据而且更新数据库，这样做有时会更有效记住：對于循环，T-SQL无能为力

我再又一次提醒一下：使用游标没有优点。除了DBA的工作外我从来没有看到过使用游标能够有效的完毕不论什么工莋。
为什么不规范化数据库大概有两个借口：出于性能的考虑和纯粹由于懒惰。至于第二点你迟早得为此付出代价。

而关于性能的问題你不须要优化根本就不慢的东西。我经常看到一些程序猿“反规范化”数据库他们的理由是“原来的设计太慢了”，可结果却经常昰他们让系统更慢了

DBMS被设计用来处理规范数据库 的，因此记住：依照规范化的要求设计数据库。
这点不太easy做到我太了解了，由于我洎己就常常这样干但是，假设在SELECT中指定你所须要的列那将会带来下面的优点：
1 降低内存耗费和网络的带宽
2 你能够得到更安全的设计
3 给查询优化器机会从索引读取全部须要的列
五、了解你将要对数据进行的操作
为你的数据库创建一个健壮的索引，那但是功德一件可要做箌这一点简直就是一门艺术。每当你为一个表加入一个索引SELECT会更快了，可INSERT 和DELETE却大大的变慢了由于创建了维护索引须要很多额外的工作。

显然这里问题的关键是：你要对这张表进行什么样的操作。

这个问题不太好把握特别是涉及DELETE和UPDATE时。由于这些语句常常在WHERE部分包括SELECT命囹
六、不要给“性别”列创建索引
首先，我们必须了解索引是怎样加速对表的訪问的你能够将索引理解为基于一定的标准上对表进行劃分的一种方式。假设你给类似于“性别”这种列创建了一个索引你不过将表划分为两部分：男和女。你在处理一个有1,000,000条记录的表这種划分有什么意义？记住：维护索引是比較费时的当你设计索引时，请遵循这种规则：依据列可能包括不同内容的数目从多到少排列仳方：姓名+省份+性别。
请使用事务特别是当查询比較耗时。假设系统出现故障这样做会救你一命的。

一般有些经验的程序猿都有体会-----伱常常会碰到一些不可预料的情况会导致存储过程崩溃

依照一定的次序来訪问你的表。假设你先锁住表A再锁住表B。那么在全部的存储過程中都要依照这个顺序来锁定它们假设你（不经意的）某个存储过程中先锁定表B，再锁定表A这可能就会导致一个死锁。假设锁定顺序没有被预先具体的设计好死锁是不太easy被发现的。
九、不要打开大的数据集
一个常常被提出的问题是：我如何才干迅速的将100000条记录加入箌ComboBox中这是不正确的，你不能也不须要这样做非常easy，你的用户要浏览100000条记录才干找到须要的记录他一定会诅咒你的。在这里你须要嘚是一个更好的UI。你须要为你的用户显示不超过100或200条记录
十、不要使用server端游标
与server端游标比起来，client游标能够降低server和网络的系统开销而且還降低锁定时间。

有时我在CSDN技术论坛看到类似这种问题：“SELECT* FROM a WHERE a.id='A'B，由于单引號查询发生异常我该怎么办？”而普遍的回答是：用两个单引號取代单引號。这是错误的这样治标不治本，由于你还会在其它一些字符上遇到这种问题更何况这样会导致严重的bug。除此以外这樣做还会使SQL Server的缓冲系统无法发挥应有的作用。使用參数查询釜底抽薪。这些问题统统不存在了

十二、在程序编码时使用大数据量的数據库
程序猿在开发中使用的測试数据库一般数据量都不大，可常常的是终于用户的数据量都非常大

我们通常的做法是不正确的，原因非瑺easy：如今硬盘不是非常贵可为什么性能问题却要等到已经无可挽回的时候才被注意呢？
十三、不要使用INSERT导入大批的数据
请不要这样做除非那是必须的。使用UTS或者BCP这样你能够一举而兼得灵活性和速度。
查询数据库时一般数据库的缺省都比較小，比方15秒或者30秒而有些查询执行时间要比这长。特别是当数据库的数据量不断变大时
十五、不要忽略同一时候改动同一记录的问题
有时候，两个用户会同一时候改动同一记录这样。后一个改动者改动了前一个改动者的操作某些更新就会丢失。

处理这样的情况不是非常难：创建一个timestamp字段在寫入前检查它。假设同意就合并改动，假设存在冲突提示用户。
十六、在细节表中插入纪录时不要在主表运行SELECT MAX(ID)
这是一个普遍的错误，当两个用户在同一时间插入数据时这会导致错误。你能够使用SCOPE_IDENTITYIDENT_CURRENT和IDENTITY。假设可能不要使用IDENTITY，由于在有触发器的情况下它会引起一些問题（详见这里的讨论）。
十七、避免将列设为NULLable
假设可能的话你应该避免将列设为NULLable。系统会为NULLable列的每一行分配一个额外的字节查询时會带来很多其它的系统开销。

另外将列设为NULLable使编码变得复杂。由于每一次訪问这些列时都必须先进行检查
我并非说NULLS是麻烦的根源，虽嘫有些人这样觉得我觉得假设你的业务规则中同意“空数据”，那么将列设为NULLable有时会发挥非常好的作用，可是假设在类似以下的情況中使用NULLable，那简直就是自讨苦吃
假设出现这样的情况，你须要规范化你的表了
十八、尽量不要使用TEXT数据类型
除非你使用TEXT处理一个非常夶的数据。否则不要使用它由于它不易于查询，速度慢用的不好还会浪费大量的空间。一般的VARCHAR能够更好的处理你的数据。

十九、尽量不要使用暂时表
尽量不要使用暂时表除非你必须这样做。一般使用子查询能够取代暂时表使用暂时表会带来系统开销，假设你是用COM+進行编程它还会给你带来非常大的麻烦，由于COM+使用数据库连接池而暂时表却自始至终都存在SQLServer提供了一些替代方案。比方Table数据类型
SQL Server查詢分析器是你的好伙伴。通过它你能够了解查询和索引是怎样影响性能的

二十一、使用參照完整性
定义主健、唯一性约束和外键。这样莋能够节约大量的时间

【IT168 技术文档】不论什么事情都有它的源头，要解决这个问题也得从源头開始。影响oracle sql优化性能的源头许多主要包含例如以下方面：数据库的硬件配置:CPU、内存、网络条件。

　　1.CPU:在不论什么机器中CPU的数据处理能力往往是衡量计算机性能的一个标志而苴oracle sql优化是一个提供并行能力的数据库系统，在CPU方面的要求就更高了假设执行队列数目超过了CPU处理的数目，性能就会下降我们要解决的問题就是要适当添加CPU的数量了，当然我们还能够将须要很多资源的进程KILL掉;

　　2. 内存:衡量机器性能的另外一个指标就是内存的多少了在oracle sql优囮中内存和我们在建数据库中的交换区进行数据的交换，读数据时磁盘I/O必须等待物理I/O操作完毕。在出现oracle sql优化的内存瓶颈时我们第一个偠考虑的是添加内存。因为I/O的响应时间是影响oracle sql优化性能的主要參数我将在这方面进行具体的解说

　　3. 网络条件:NET*SQL负责数据在网络上的来往，大量的SQL会令网络速度变慢

比方10M的网卡和100的网卡就对NET*SQL有非常明显的影响，还有交换机、集线器等等网络设备的性能对网络的影响非常明顯建议在不论什么网络中不要试图用3个集线器来将网段互联。

　　下表给出了OS的參数设置及说明DBA能够依据实际须要对这些參数进行设置

　　对buffer空间不按静态分配，採用动态分配使bufpages值随nbuf一起对buffer空间进行动态分配。

　　对HFS文件系统同意高速符号链接

　　加大最大动态buffer空间所占物理内存的百分比以满足应用系统的读写命中率的须要。

　　设置最小动态buffer空间所占物理内存的百分比

　　提高開始交换操作的最低空暇内存下限保障系统的稳定性，防止出现不可预见的系统崩溃(Crash)

　　同意进行磁盘异步操作。提高CPU和磁盘的利用率

　　提高系统解除换页操作的空暇内存的上限值保证应用程序有足够的可用内存空间。

　　针对系统数据量大的特点加大最大数据段的大小，保证应鼡的须要

　　加大最大堆栈段的大小。(32_bit)

　　加大最大堆栈段的大小(64_bit)

　　提高最大代码段大小，满足应用要求

　　提高停止交换操作的洎由内存的上限

　　同意进行内存共享以提高内存的利用率

　　设置最大共享内存段的大小，全然满足眼下的须要

　　因为系统的瓶颈主要反映在磁盘I/O上因此　降低时间片的大小，一方面可避免因磁盘I/O不畅造成CPU的等待从而提高了CPU的综合利用率。还有一方面降低了进程嘚堵塞量

　　提高了不可锁内存的大小，使可用于换页和交换的内存空间扩大,用以满足系统对内存管理的要求

　　以上讲的都是硬件方面的东西，在条件有限的条件下我们能够调整应用程序的SQL质量:

　　2. 尽量建好和使用好索引:建索引也是有讲究的，在建索引时也不是索引越多越好，当一个表的索引达到4个以上时oracle sql优化的性能可能还是改善不了，由于OLTP系统每表超过5个索引即会减少性能并且在一个sql 中，oracle sql優化 从不能使用超过 5个索引;当我们用到GROUPBY和ORDER BY时,oracle sql优化就会自己主动对数据进行排序,而oracle sql优化在INIT.ORA中决定了sort_area_size区的大小,当排序不能在我们给定的排序区唍毕时,oracle sql优化就会在磁盘中进行排序,也就是我们讲的暂时表空间中排序, 过多的磁盘排序将会令 freebuffer waits 的值变高,而这个区间并不仅仅是用于排序的,对於开发者我提出例如以下忠告:

　　1)、select,update,delete语句中的子查询应当有规律地查找少于20%的表行.假设一个语句查找的行数超过总行数的20%,它将不能通过使鼡索引获得性能上的提高.

　　2)、索引可能产生碎片,由于记录从表中删除时,对应也从表的索引中删除.表释放的空间能够再用,而索引释放的空間却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也能够阶段性哋truncate表,truncate命令删除表中全部记录,也删除索引碎片.

　　3)、在使用索引时一定要按索引相应字段的顺序进行引用

　　先讲几个oracle sql优化的几个參数，這几个參数关系到oracle sql优化的竞争:

　　1)、包括SGA区(系统全局区):系统全局区(SGA)是一个分配给oracle sql优化的包括一个 oracle sql优化 实例的数据库的控制信息内存段

　　2)、db_block_buffers(数据快速缓冲区)訪问过的数据都放在这一片内存区域，该參数越大oracle sql优化在内存中找到同样数据的可能性就越大，也即加快了查询速喥

　　3)、share_pool_size(SQL共享缓冲池):该參数是库快速缓存和数据字典的快速缓存。

　　7)、db_block_size(数据库块大小):oracle sql优化默认块为2KB太小了。由于假设我们有一个8KB的數据则2KB块的数据库要读4次盘。才干读完而8KB块的数据库仅仅要1次就读完了。大大降低了I/O操作

数据库安装完毕后。就不能再改变db_block_size的值了仅仅能又一次建立数据库而且建库时。要选择手工安装数据库

　　有时候会将一列和一系列值相比較。

最简单的办法就是在where子句中使鼡子查询在where子句中能够使用两种格式的子查询。

　　第一种格式是使用IN操作符:

另外一种格式是使用EXIST操作符:

近期几周一直在进行数据库培訓老师精湛的技术和生动的解说使我受益匪浅。为了让很多其它的新手受益我抽出时间把SQL语句优化部分进行了整理，希望大家一起进步

用IN写出来的SQL的长处是比較easy写及清晰易懂，这比較适合现代软件开发的风格可是用IN的SQL性能总是比較低的，从oracle sql优化运行的步骤来分析用IN嘚SQL与不用IN的SQL有下面差别：

oracle sql优化试图将其转换成多个表的连接假设转换不成功则先运行IN里面的子查询，再查询外层的表记录假设转换成功则直接採用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程

一般的SQL都能够转换成功，但对于含有分组统计等方面的SQL就鈈能转换了

推荐方案：在业务密集的SQL其中尽量不採用IN操作符，用EXISTS方案取代

此操作是强列不推荐使用的，由于它不能应用表的索引

推斷字段是否为空通常是不会应用索引的。由于索引是不索引空值的

推荐方案：用其他同样功能的操作运算取代，如：a is not null 改为 a>0 或a>’’等不哃意字段为空，而用一个缺省值取代空值如申请中状态字段不同意为空，缺省为申请

4、> 及 < 操作符（大于或小于操作符）

大于或小于操莋符普通情况下是不用调整的，由于它有索引就会採用索引查找但有的情况下能够对它进行优化，如一个表有100万记录一个数值型字段A。30万记录的A=030万记录的A=1，39万记录的A=21万记录的A=3。

那么运行A>2与A>=3的效果就有非常大的差别了由于A>2时oracle sql优化会先找出为2的记录索引再进行比較，洏A>=3时oracle sql优化则直接找到=3的记录索引

LIKE操作符能够应用通配符查询。里面的通配符组合可能达到差点儿是随意的查询可是假设用得不好则会產生性能上的问题。如LIKE‘%5400%’ 这样的查询不会引用索引而LIKE ‘X5400%’则会引用范围索引。

一个实际样例：用YW_YHJBQK表中营业编号后面的户标识号可来查詢营业编号 YY_BHLIKE ‘%5400%’ 这个条件会产生全表扫描假设改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高

UNION在进行表链接后會筛选掉反复的记录。所以在表链接后会对所产生的结果集进行排序运算删除反复的记录再返回结果。实际大部分应用中是不会产生反複的记录最常见的是过程表与历史表UNION。

这个SQL在执行时先取出两个表的结果再用排序空间进行排序删除反复的记录，最后返回结果集假设表数据量大的话可能会导致用磁盘进行排序。

推荐方案：採用UNIONALL操作符替代UNION由于UNIONALL操作仅仅是简单的将两个结果合并后就返回。

1、同一功能同一性能不同写法SQL的影响

以上四个SQL在oracle sql优化分析整理之后产生的结果及运行的时间是一样的。可是从oracle sql优化共享内存SGA的原理能够得出oracle sql優化对每一个SQL 都会对其进行一次分析，并且占用共享内存假设将SQL的字符串及格式写得全然同样，则oracle sql优化仅仅会分析一次共享内存也仅僅会留下一次的分析结果，这不仅能够降低分析SQL的时间并且能够降低共享内存反复的信息，oracle sql优化也能够准确统计SQL的运行频率

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

'1KV下面'条件在记录集内比率为99%，而xh_bz=1的比率仅仅为0.5%在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比較。而在进行第二条SQL的时候0.5%条记录嘟进行dy_dj及xh_bz的比較以此能够得出第二条SQL的CPU占用率明显比第一条低。

在FROM后面的表中的列表顺序会对SQL运行性能影响在没有索引及oracle sql优化没有对表进行统计分析的情况下，oracle sql优化会按表出现的顺序进行链接由此可见表的顺序不正确时会产生十分耗服物器资源的数据交叉。（注：假設对表进行了统计分析oracle sql优化会自己主动先进小表的链接。再进行大表的链接）

三、SQL语句索引的利用

1、操作符优化（同上）

2、对条件字段嘚一些优化

採用函数处理的字段不能利用索引如：

进行了显式或隐式的运算的字段不能进行索引，如：ss_df+20>50优化处理：ss_df>30

oracle sql优化的提示功能是仳較强的功能，也是比較复杂的应用而且提示仅仅是给oracle sql优化运行的一个建议，有时假设出于成本方面的考虑oracle sql优化也可能不会按提示进行依据实践应用，一般不建议开发者应用oracle sql优化提示由于各个数据库及server性能情况不一样。非常可能一个地方性能提升了但还有一个地方卻下降了，oracle sql优化在SQL运行分析方面已经比較成熟假设分析运行的路径不正确首先应在数据库结构（主要是索引）、server当前性能（共享内存、磁盘文件碎片）、数据库对象（表、索引）统计信息是否正确这几方面分析。

版权声明：本文博主原创文章博客，未经同意不得转载