关于SQL文优化问题总结
关于SQL文优化问题总结
【摘要】实际系统中遇到性能问题是非常常见的，性能优化有许多方面，其中包括硬件方面，软件方面，包括服务器端，客户端等等。
本文重点基于oracle分析了影响sql文性能的原因，然后列举了几点性能优化的对策，希望给开发人员在编码时提供帮助，给sql的性能问题调查者提供一个方向。
【关键词】oracle；性能问题；sql文优化
一、问题提出
之前有个项目，其中的批处理定期调用一个存储过程，在测试环境中运行没有问题，但是正式运行出现了错误，执行存储过程时出现了错误：提示是表空间不足。
为了解决这个问题，笔者对sql 文的性能优化进行了学习和研究。
二、问题调查与解决
由于该存储过程内容比较多，大概有3000多行，也不能判断那部分出了问题，首先在可能出现问题的地方追加了log信息。
由于测试环境中该问题不能再现，所以代码更新到了实际环境中进行运行，通过log发现是在执行某个sql文时出的错误，这个sql文涉及到了10多个表，而其中表中的数据量比较大。
执行时用到的临时表空间高达40g，后来通过调查对sql的进行了调整，只是修改了where条件中其中两个条件的顺序，这个问题就解决了。
三、sql文性能原因分析
（1）在大记录集上进行高成本操作，如使用了引起排序的谓词
等。
（2）过多的i/o操作（含物理i/o与逻辑i/o），最典型的就是未建立恰当的索引，导致对查询表进行全表扫描。
减少访问数据库的次数，就能实际上减少oracle的工作量。
（3）处理了太多的无用记录，如在多表连接时过滤条件位置不当导致中间结果集包含了太多的无用记录。
（4）未充分利用数据库提供的功能，如查询的并行化处理等。
四、sql文性能优化总结
（1）建立恰当的索引。
对经常进行排序和连接操作的字段建立索引。
（2）避免使用”*”，sql文中引用”*”，使用起来的确非常方便，但是效率非常低，主要是oracle在解析的过程中，会将”*”一次转化成所有的列名，这个工作是通过查询数据字典完成的。
这就意味着消耗更多的时间。
（3）尽量避免多表关联。
（4）避免使用消耗资源的操作，带有distinct，union，minus，intersect，order by的sql语句会启动sql引擎执行消耗资源的排序功能。
distinct 需要一次排序操作，其他的至少需要执行二次排序。
通常带有执行union，minus，intersect的sql语句都可以通过其他方式回避。
例如：select distinct a.no， from a，b where a.no=b.no 可以替换为效率更高的exists来实现，select a.no， from a where exists（select 1 from b whre b.no=a.no）。
（5）避免在索引列上使用函数。
例如：
select no from a where a.score * 2>180可以修改为select no from a where a.score>180/2。
（6）避免在索引列上使用not。
not会产生和在索引列上使用函数相同的影响。
当oracle遇到not 时，他就会停止使用索引转而执行全表扫描。
（7）避免在索引列上使用is null，is not
null。
（8）减少对表的查询。
在含有自查询的语句中，要特别注意减少对表的查询。
（9）注意where字句的连接顺序。
oracle原则上采用自下而上的顺序解析where子句，根据据这个原理，当在where子句中有多个表联接时，where子句中排在最后的表应当是返回行数可能最少的表，有过滤条件的子句应放在where子句的最后。
（10）使用表的别名（alias）：当在sql语句中连接多个表时，请使用表的别名并把别名前缀于每个column上.这样一来，就可以减少解析的时间并减少那些由column歧义引起的语法错误。
（11）用exists替代in、用not exists替代not in。
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接，在这种情况下，使用exists（或not exists）通常将提高查询的效率。
在子查询中，not in子句将执行一个内部的排序和合并。
无论在哪种情况下，not in都是最低效的（因为它对子查询中的表执行了一个全表遍历）。
为了避免使用not in，我们可以把它改写成外连接（outer joins）或not exists。
（12）sql语句用大写的。
因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行。
（13）用>=替代>。
高效：select*from emp
where deptno>=4；低效：select*from emp where deptno>3。
两者的区别在于，前者dbms将直接跳到第一个dept等于4的记录
而后者将首先定位到deptno=3的记录并且向前扫描到第一个dept 大于3的记录。
sql语言在数据库应用中占有非常重要的地位，其性能的优劣直接影响着整个信息系统的可用性。
因此对于开发人员来说，理解sql 调优的基本原理，这样可能避免一些不必要的问题。
理论上sql的优化方法很多，具体的效果好需要在实际的环境中进行验证。
有可能需要多个方法并用。
参考文献
[1]徐凤梅.关系数据库中sql语言查询的优化策略[j].广西轻工业.2009（5）。
浅谈FireBird数据库SQL语句的优化
浅谈FireBird数据库SQL语句的优化作者：刘华来源：《电脑知识与技术》2016年第16期摘要：数据库是计算机信息管理系统的核心部分，必不可少的。
该文主要分析了基于FireBird数据库的SQL语句优化技术，通过实例进行优化技术前后性能指标的分析与总结，阐述了SQL语句的优化对数据库系统性能的改善和提升起到了重要的作用。
关键词：FireBird；数据库；SQL语句；优化中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）16-0018-021 数据库优化背景知识数据库最常见的优化手段是对硬件的升级，据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。
应用程序的优化分为源代码和SQL语句优化。
由于涉及对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高，而对数据库性能提升收效有限。
SQL语句在执行中消耗了70%～90%的数据库资源，对SQL语句进行优化不会影响程序逻辑，而对于SQL语句的优化成本较低、收益却比较高，所以对SQL语句进行优化改进，对于提高数据库性能和效率是非常有必要的。
2 分析SQL优化问题许多程序员认为查询优化与编写的SQL语句关系不大，这是错误的认识，一个好的SQL 查询语句往往可以使程序性能提高数十倍，同时减轻数据库服务器的承载压力。
实际应用程序开发过程中还是以用户提交的SQL语句作为系统优化的基础，很难设想一个原本糟糕的SQL 查询语句经过系统的优化之后会变得高效.查询优化技术在关系数据库系统中有着非常重要的地位，关系数据库系统和非过程化的SQL语言能够取得巨大的成功，关键是得益于查询优化技术的发展。
从本质上讲。
用户希望查询的运行速度能够尽可能地快，无论是将查询运行的时间从10分钟缩减为1分钟，还是将运行的时间从2秒缩短为1秒钟，最终的目标都是减少运行时间。
对医院数据库系统中SQL语句优化的探讨
无 损分 解 指 的是对 关系 模式 分解 时 ，原 关 系模 型下任 一 合法
的 关系 值在 分 解之 后应 能通 过 自然联 接运 算 恢复 起来 。 相 互独 立 是指 分解 后 的新 关系 之 间相互 独 立 ，对一 个关 系 内 容 的修 改不 应 该影 响到 另一 关 系。 三 、优 化 技术 在查 询 中的应 用
Ａｂｓｒ ｃ ： ｔｒ ｙ ａ ｓ ｆ ｉ ｏ ｍａ ｉｎ ｃ ｎｓｒ ｔｏｎｏ ｒ ｈｏ ｐｉ ｌ ｈ ｓ ｂｅ ｏ ｅ ｏ ｔ ａ ｔＡｆｅ ｅ ｒ ｏ ｎｆ ｒ ｔｏ ｏ ｔｕｃｉ ，ｕ ｓ ｔ ａ ｃ ｍ ａ ｃ ｍｐｒｈｅ ｉ ｎｆ ｒ ａｉｎ ｅ ｈ ｏ ｏ ｙ ｆ ａ ａ ｅ ｎｓｖｅ ｉ ｏ ｍ ｔｏ ｔｃ ｎ ｌ ｇ ｏ
ａ ａ ｓ， ｄａ ｏｍａ ｅｈｇ ｅ ｎ ｓＯ ｄ ｔ ａ ｅ ｎ ｌ ｄ ｉｈｄ ｍａ ｄ ｎ ｔｅ ＡＣ ｇ ａ ｓｅ ｓ ｅ ｄｏ ｅｎ ｔ ｏ ． ｅ ｆｒ， ｅｏ ｔ ｚ ｔ ｎｏ ｅＳ Ｌ ｂ ａ ｓ ｈ Ｐ Ｓｉ ｅｔ ｆ ｅ ｆ ｈ ｅ ｒ Ｔ ｒ ｏｅ ｐｉ ａ ｏ ｆ ｈ Ｑ ｍａ ｒ ｎ ｒｐ ｔ ｗ ｋ ｈ ｅ ｈ ｔ ｍｉ ｉ ｔ
Ｌ ａ ｇｉｎ ｕＦ ｎ ｊ ａ （ａ ｇｉ ｇＣｔ， ａ ｇ ｏ ｇＰｏ ｉ ｅＨ ｓ ｉ ｌｆ ｅ ｐ，ａ ｇｉ ｇ ５ ９ ０ ，ｈｎ ） Ｙ ｎ ｊ ｎ ｉ Ｇｕ ｎ ｄ ｎ ｒｖｎ ｏ ｐ ａ ｏ ｏ ｌ Ｙ ｎ ｊｎ ２ ５ ０Ｃ ｉ ａ ｙ ｃ ｔ Ｐ ｅ ａ ａ
５９ ０ ２ ５０）
摘 要 ：经过 多年 的信 息化建 设 ，我 们 医院 变成 了全 面信 息化 的现 代化 医院 。特别 近 两年 来 ， 医院信 息 系统 （ Ｓ 、 ＨＩ ） 实验 室信 息 管理 系统 （ Ｉ ）以及 影像 归档 和 通信 系统 （ Ａ ）系统 的上 线 ， 大大增 加 了数据 库 的数 据 量 ，影 像 归档 和通 ＬＳ Ｐ ＣＳ 信 系统 （ Ａ Ｓ Ｐ Ｃ ）的 图片传输 对 网络速 度 也提 出了很 高的要 求。 因此 ，Ｓ ＱＬ语 句的 优化 就显 得格 外重 要 了 。 关键 词 ： 医院信 息 系统 ；数据 库 ；５ ＱＬ
对数据库中SQL语句的优化技术进行研究——对LECCO SQL Expert的分析与研究
通过分析SQL语句的执行计划优化SQL(总结)
l 选择你的数据块的最佳大小。 -- 原则上来说大一些的性能较好。
l 分布你的数据，使得一个节点使用的数据本地存贮在该节点中。
调整产品系统
本节描述对应用系统快速、容易地找出性能瓶颈，并决定纠正动作的方法。这种方法依赖于对Oracle服务器体系结构和特性的了解程度。在试图调整你的系统前，你应熟悉Oracle调整的内容。
表之间的连接
如何产生执行计划
如何分析执行计划
ቤተ መጻሕፍቲ ባይዱ 如何干预执行计划 - - 使用hints提示
具体案例分析
第6章 其它注意事项
附录
————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
通过分析SQL语句的执行计划优化SQL(总结)
做DBA快7年了，中间感悟很多。在DBA的日常工作中，调整个别性能较差的SQL语句时一项富有挑战性的工作。其中的关键在于如何得到SQL语句的执行计划和如何从SQL语句的执行计划中发现问题。总是想将日常经验的点点滴滴总结一下，但是直到最近才下定决心，总共花了3个周末时间，才将其整理成册，便于自己日常工作。不好意思独享，所以将其贴出来。
图1-1 在应用生命周期中调整的代价
图1-2 在应用生命周期中调整的收益
当然，即使在设计很好的系统中，也可能有性能降低。但这些性能降低应该是可控的和可以预见的。
调整目标
《数据库高效优化：架构、规范与SQL技巧》读书笔记模板
读书笔记
本书以大量案例为依托，系统讲解了SQL语句优化的原理、方法及技术要点，尤为注重实践，在章节中引入 了大量的案例，便于学习者实践、测试，反复揣摩。
SQL是最重要的关系数据库操作语言。本书以大量案例为依托，系统讲解了SQL语句优化的原理、方法及技术 要点，尤为注重实践，在章节中引入了大量的案例，便于学习者实践、测试，反复揣摩。
目录分析
第0章引言
第1章与SQL优 化相关的几个 案例
案例1一条SQL引发的“血案” 案例2糟糕的结构设计带来的问题 案例3规范SQL写法好处多 案例4 “月底难过” 案例5 COUNT()到底能有多快 案例6 “抽丝剥茧”找出问题所在
第2章优化器与成本 第3章执行计划
第4章统计信息
第5章 SQL解析与游 标
第6章绑定变量
第7章 SQL优化相关 对象
第8章 SQL优化相关 存储结构
第9章特有SQL
2.1优化器 2.2成本
3.1概述 3.2解读执行计划 3.3执行计划操作
4.1统计信息分类 4.2统计信息操作
5.1解析步骤 5.2解析过程 5.3游标示例
6.1使用方法 6.2绑定变量与解析 6.3游标共享
第13章半连接与反连 接
第15章子查询
第14章排序
第16章并行
10.1查询转换的分类及说明 10.2查询转换——子查询类 10.3查询转换——视图类 10.4查询转换——谓词类 10.5查询转换——消除类 10.6查询转换——其他
11.1表访问路径 11.2 B树索引访问路径 11.3位图索引访问路径 11.4其他访问路径
7.1表 7.2字段 7.3索引 7.4视图 7.5函数 7.6数据链（DB_LINK）
程序员个人工作总结范文（3篇）
程序员个人工作总结范文这一年来的工作已经结束了，我知道这对我而言是有很大的提高，作为一名程序员我坚定的认为自己是可以做的更好，在未来的学习当中我还是深有体会的，以后在学习当中，在这一点上面我希望自己可以做的更加的到位，作为一名技术人员，我还是做的非常不错的，希望自己在这一年来的工作当中我可以继续维持好的状态。
这一年来的工作当中，我现在还是希望可以做的更好，公司对我的培养还是比较多的，在这方面我是坚定的体会到了这一点，在未来的工作当中，我是坚持的做好了很多的事情的，年终之际我回顾起来确实是获得了很多，我也希望自己在以后的学习当中，我深刻的意识到了这一点，过去一年来我也是独完成了很多的工作，也和公司的同事一起合作了一些项目，在这个过程当中，我也确实是深刻的意识到了这一点，我知道在这方面我是维持了一个好的状态，现在回顾起来我清楚的意识到了这一点，通过这次的项目我还是深有体会。
我绝得工作能力是需要不断的去落实，对于这一点我是感觉非常有意义的，年终之际，在这个过程当中，我清楚的意识到了这些细节是可以做的更加到位，我觉得以后还会有更多的事情可以做好，这一年来的工作结束了我也是希望自己可以把工作做的更好，想要把工作做的更好，我还是深有体会，在一些事情上面，我确实感觉很有意义，在工作当中我进一步的调整好了自己各个方面的职责，公司对我个人能力还是做出了很多的判断，我相信在这一点上面我知道自己各个方面是非常有意义的，在公司做好自己分内的职责，当然我也是意识到了自身的努力还是值得的`，我也想要为公司争取更多的价值。
我也是清楚的意识到了自己的不足，虽然每天的工作很充实，但是在一些项目上面，还是做的不够好，出现了一些细节的问题，这也确实是我应该要去调整好的，我会改正自己的不足之处，在以后的学习当中，我会继续做好自己分内的职责，在程序工作方面应该要更加的细心，我会让自己做的更好的，感激公司领导的关照，以后我也一定会让自己做出更好努力，努力提高自己的工作能力，做技术工作让我感觉很有意义，新的一年我一定会认真做好工作。
SQL Server数据库对策与优化
世纪 ７ ０年代 ，目前我国数据库建设有 了较 大发展 ，但从对数 据库系统的应用效果上 与发 达国家之间仍然存在较大 的差距 ，
比如 Ｓ ＬＳ ｒｅ 数 据 库 其 中最 为 显 著 的 就 是 数 据 库 的 性 能 问 Ｑ ｅ ｒ ｖ 题 。随 着 Ｓ ＬＳ ｒ ｒ 据 库 规 模 的不 断扩 大 ，Ｓ ＬＳｒｅ 数 据 Ｑ ｅ ｅ 数 ｖ Ｑ ｅ ｒ ｖ 库 应 用 系 统 能 否 正 常 倍 受 关 注 。 因此 ，基 于 Ｓ ＬＳｒｅ 数 据 Ｑ ｅｖｒ 库 系 统 的 使 用 与 优 化 对 于 整 个 系 统 的正 常 运 行 起 着 重 要 的 作 用 。Ｓ ＬＳｒｅ 数 据 库 的优 化 涉 及 到 多 个 层 面 ，通 过 统 一 规 划 Ｑ ｅｖｒ
最多能利用 ２ Ｂ虚拟内存 ，这也是最大 的设置值 。还 有一点 Ｇ
必 须 考 虑 的 是 它 的 所 有 服 务也 要 占用 内 存 。 还 有 中央 处 理 器 ， Ｃ Ｕ是 计 算 机 在 运 行 中 最 重 要 的 部 分 ，根 据 自己 的 具 体 需 要 Ｐ
调 整 可 以提 高 Ｓ ＬＳ ｒ ｒ 据 库 的稳 定 性 和可 用 性 ，保 障 Ｑ ｅｖ 数 ｅ
Ｄ ＴＢＳ Ｎ ＦＲ Ａ１ＮＭ ＮＧ Ｍ Ｎ ＡＡＡＥＡＤＩ ０ 库 与 信 息 管 理
Ｓ ＬＳ ｒｅ 数 据库 对 策 与优 化 Ｑ ｅｖｒ
王 胜 利
（ 内蒙古锡林浩特市人 民医院，锡林浩特 ０ ６ ０ ） ２０ ０
摘 要 ： 随 着计 算 机 科 学技 术和 信 息 技 术 的 发展 ，各 个企 业 都 建 立 起 了各 自的信 息 系统 ，而数 据 库 作 为 信 息 系统 的
ｔｅｅｓｓ ｍ ． ａｙａ ｅｔ ｎ ｒ ａ ｅｄ ｔ ａｅｐｒ ｒ ｎｅｏ Ｑ ｅｖｒ Ｄ ｔｂ ｓ ｐ ｒ ｒ ａ ｃ ｐｉ ｚｔ ｎ ｈ ｓ ｙｔ ｓ ｏｍ ｎ ｔ ｎｉ ｓａ ｐｉ ｔ ｔ ａ ｂ ｓ ｅｆ ｍａｃ ｎＳ Ｉ Ｓｒｅ． ａ ａｅ ｅ ｏｍ ｎｅＯ ｔ ａｉ ｅ Ｓ ｔ ｏ ｅ ｄｏｈ ａ ｏ ａ ｆ ｍｉ ｏ
SQL语句优化--OR语句优化案例
SQL语句优化--OR语句优化案例从上海来到温州，看了前⼏天监控的sql语句和数据变化，发现有⼀条语句的io次数很⼤，达到了150万次IO，⽽两个表的数据也就不到20万，为何有如此多的IO次数，下⾯是执⾏语句：select ws.nodeid,ststepid,wi.curstepid from Workflowinfo wi,Workflowstep ws where ws.workflowid='402881db1b441e6f011c0cff320e4766'and (ststepid = ws.id or (wi.curstepid = ws.id and isreceived=1and issubmited =1))执⾏IO统计结果如下：(22⾏受影响)表'workflowstep'。
扫描计数1，逻辑读取23次，物理读取0次，预读0次，lob 逻辑读取0次，lob 物理读取0次，lob 预读0次。
表'Worktable'。
扫描计数4，逻辑读取1490572次，物理读取0次，预读0次，lob 逻辑读取0次，lob 物理读取0次，lob 预读0次。
表'workflowinfo'。
扫描计数4，逻辑读取12208次，物理读取0次，预读0次，lob 逻辑读取0次，lob 物理读取0次，lob 预读0次。
表'Worktable'。
扫描计数0，逻辑读取0次，物理读取0次，预读0次，lob 逻辑读取0次，lob 物理读取0次，lob 预读0次。
执⾏计划如下：这⾥发现：主要是嵌套循环算法占的开销最⼤。
个⼈感觉是“Or”引起的性能问题，后来根据业务逻辑改写。
如下：语句修改如下：select ws.nodeid,ststepid,wi.curstepid from Workflowinfo wi, Workflowstep wswhere ws.workflowid='402881db1b441e6f011c0cff320e4766'and (ststepid = ws.id)union allselect ws.nodeid,ststepid,wi.curstepid from Workflowinfo wi, Workflowstep ws where ws.workflowid='402881db1b441e6f011c0cff320e4766'and (wi.curstepid = ws.id and isreceived=1查询IO次数如下:(22⾏受影响)表'workflowinfo'。
SQL优化的几种方法及总结
SQL优化的⼏种⽅法及总结优化⼤纲：通过explain 语句帮助选择更好的索引和写出更优化的查询语句。
SQL语句中的IN包含的值不应该过多。
当只需要⼀条数据的时候，使⽤limit 1。
如果限制条件中其他字段没有索引，尽量少⽤or。
尽量⽤union all代替union。
不使⽤ORDER BY RAND()。
区分in和exists、not in和not exists。
使⽤合理的分页⽅式以提⾼分页的效率。
查询的数据过⼤，可以考虑使⽤分段来进⾏查询。
避免在where⼦句中对字段进⾏null值判断。
避免在where⼦句中对字段进⾏表达式操作。
必要时可以使⽤force index来强制查询⾛某个索引。
注意查询范围，between、>、<等条件会造成后⾯的索引字段失效。
关于JOIN优化。
优化使⽤1、mysql explane ⽤法 explane显⽰了mysql如何使⽤索引来处理select语句以及连接表。
可以帮助更好的索引和写出更优化的查询语句。
EXPLAIN SELECT*FROM l_line WHERE `status` =1and create_at >'2019-04-11';explain字段列说明table：显⽰这⼀⾏的数据是关于哪张表的type：这是重要的列，显⽰连接使⽤了何种类型。
从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和allpossible_keys：显⽰可能应⽤在这张表中的索引。
如果为空，没有可能的索引。
可以为相关的域从where语句中选择⼀个合适的语句key：实际使⽤的索引。
如果为null，则没有使⽤索引。
很少的情况下，mysql会选择优化不⾜的索引。
这种情况下，可以在select语句中使⽤use index（indexname）来强制使⽤⼀个索引或者⽤ignore index（indexname）来强制mysql忽略索引key_len：使⽤的索引的长度。
SQLServer多表查询优化方案总结
SQLServer多表查询优化⽅案总结SQL Server多表查询的优化⽅案是本⽂我们主要要介绍的内容，本⽂我们给出了优化⽅案和具体的优化实例，接下来就让我们⼀起来了解⼀下这部分内容。
1.执⾏路径ORACLE的这个功能⼤⼤地提⾼了SQL的执⾏性能并节省了内存的使⽤:我们发现,单表数据的统计⽐多表统计的速度完全是两个概念.单表统计可能只要0.02秒,但是2张表联合统计就可能要⼏⼗秒了.这是因为ORACLE只对简单的表提供⾼速缓冲(cache buffering) ,这个功能并不适⽤于多表连接查询..数据库管理员必须在init.ora中为这个区域设置合适的参数,当这个内存区域越⼤,就可以保留更多的语句,当然被共享的可能性也就越⼤了.2.选择最有效率的表名顺序(记录少的放在后⾯)ORACLE的解析器按照从右到左的顺序处理FROM⼦句中的表名,因此FROM⼦句中写在最后的表(基础表 driving table)将被最先处理. 在FROM⼦句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.当ORACLE处理多个表时, 会运⽤排序及合并的⽅式连接它们.⾸先,扫描第⼀个表(FROM⼦句中最后的那个表)并对记录进⾏派序,然后扫描第⼆个表(FROM⼦句中最后第⼆个表),最后将所有从第⼆个表中检索出的记录与第⼀个表中合适记录进⾏合并.例如:表 TAB1 16,384 条记录表 TAB2 1条记录选择TAB2作为基础表 (最好的⽅法)select count(*) from tab1,tab2 执⾏时间0.96秒选择TAB2作为基础表 (不佳的⽅法)select count(*) from tab2,tab1 执⾏时间26.09秒如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引⽤的表.例如: EMP表描述了LOCATION表和CATEGORY表的交集.1. SELECT *2. FROM LOCATION L ,3. CATEGORY C,4. EMP E5. WHERE E.EMP_NO BETWEEN 1000 AND 20006. AND E.CAT_NO = C.CAT_NO7. AND E.LOCN = L.LOCN将⽐下列SQL更有效率1. SELECT *2. FROM EMP E ,3. LOCATION L ,4. CATEGORY C5. WHERE E.CAT_NO = C.CAT_NO6. AND E.LOCN = L.LOCN7. AND E.EMP_NO BETWEEN 1000 AND 20003.WHERE⼦句中的连接顺序(条件细的放在后⾯)ORACLE采⽤⾃下⽽上的顺序解析WHERE⼦句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最⼤数量记录的条件必须写在WHERE⼦句的末尾.例如:(低效,执⾏时间156.3秒)1. SELECT …2. FROM EMP E3. WHERE SAL > 500004. AND JOB = ‘MANAGER’5. AND 25 < (SELECT COUNT(*) FROM EMP6. WHERE MGR=E.EMPNO);7. (⾼效,执⾏时间10.6秒)8. SELECT …9. FROM EMP E10. WHERE 25 < (SELECT COUNT(*) FROM EMP11. WHERE MGR=E.EMPNO)12. AND SAL > 5000013. AND JOB = ‘MANAGER’;4.SELECT⼦句中避免使⽤'* '当你想在SELECT⼦句中列出所有的COLUMN时,使⽤动态SQL列引⽤ '*' 是⼀个⽅便的⽅法.不幸的是,这是⼀个⾮常低效的⽅法. 实际上,ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个⼯作是通过查询数据字典完成的, 这意味着将耗费更多的时间.5.减少访问数据库的次数当执⾏每条SQL语句时, ORACLE在内部执⾏了许多⼯作: 解析SQL语句, 估算索引的利⽤率, 绑定变量 , 读数据块等等. 由此可见, 减少访问数据库的次数 , 就能实际上减少ORACLE的⼯作量.⽅法1 (低效)1. SELECT EMP_NAME , SALARY , GRADE2. FROM EMP3. WHERE EMP_NO = 342;4. SELECT EMP_NAME , SALARY , GRADE5. FROM EMP6. WHERE EMP_NO = 291;⽅法2 (⾼效)1. SELECT A.EMP_NAME , A.SALARY , A.GRADE,2. B.EMP_NAME , B.SALARY , B.GRADE3. FROM EMP A,EMP B4. WHERE A.EMP_NO = 3425. AND B.EMP_NO = 291;6.删除重复记录最⾼效的删除重复记录⽅法 ( 因为使⽤了ROWID)1. DELETE FROM EMP E2. WHERE E.ROWID > (SELECT MIN(X.ROWID)3. FROM EMP X4. WHERE X.EMP_NO = E.EMP_NO);7.⽤TRUNCATE替代DELETE当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) ⽤来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执⾏删除命令之前的状况)，⽽当运⽤TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运⾏后,数据不能被恢复.因此很少的资源被调⽤,执⾏时间也会很短.8.尽量多使⽤COMMIT只要有可能,在程序中尽量多使⽤COMMIT, 这样程序的性能得到提⾼,需求也会因为COMMIT所释放的资源⽽减少:COMMIT所释放的资源:a. 回滚段上⽤于恢复数据的信息.b. 被程序语句获得的锁c. redo log buffer 中的空间d. ORACLE为管理上述3种资源中的内部花费(在使⽤COMMIT时必须要注意到事务的完整性,现实中效率和事务完整性往往是鱼和熊掌不可得兼)9.减少对表的查询在含有⼦查询的SQL语句中,要特别注意减少对表的查询.例如：低效：1. SELECT TAB_NAME2. FROM TABLES3. WHERE TAB_NAME = ( SELECT TAB_NAME4. FROM TAB_COLUMNS5. WHERE VERSION = 604)6. AND DB_VER= ( SELECT DB_VER7. FROM TAB_COLUMNS8. WHERE VERSION = 604⾼效：1. SELECT TAB_NAME2. FROM TABLES3. WHERE (TAB_NAME,DB_VER)4. = ( SELECT TAB_NAME,DB_VER)5. FROM TAB_COLUMNS6. WHERE VERSION = 604)Update 多个Column 例⼦:低效：1. UPDATE EMP2. SET EMP_CAT = (SELECT MAX(CATEGORY) FROM EMP_CATEGORIES),3. SAL_RANGE = (SELECT MAX(SAL_RANGE) FROM EMP_CATEGORIES)4. WHERE EMP_DEPT = 0020;⾼效:1. UPDATE EMP2. SET (EMP_CAT, SAL_RANGE)3. = (SELECT MAX(CATEGORY) , MAX(SAL_RANGE)4. FROM EMP_CATEGORIES)5. WHERE EMP_DEPT = 0020;10.⽤EXISTS替代IN,⽤NOT EXISTS替代NOT IN在许多基于基础表的查询中,为了满⾜⼀个条件,往往需要对另⼀个表进⾏联接.在这种情况下, 使⽤EXISTS(或NOT EXISTS)通常将提⾼查询的效率.低效:1. SELECT *2. FROM EMP (基础表)3. WHERE EMPNO > 04. AND DEPTNO IN (SELECT DEPTNO5. FROM DEPT6. WHERE LOC = ‘MELB’)⾼效:1. SELECT *2. FROM EMP (基础表)3. WHERE EMPNO > 04. AND EXISTS (SELECT ‘X’5. FROM DEPT6. WHERE DEPT.DEPTNO = EMP.DEPTNO7. AND LOC = ‘MELB’)(相对来说,⽤NOT EXISTS替换NOT IN 将更显著地提⾼效率)在⼦查询中,NOT IN⼦句将执⾏⼀个内部的排序和合并. ⽆论在哪种情况下,NOT IN都是最低效的 (因为它对⼦查询中的表执⾏了⼀个全表遍历). 为了避免使⽤NOT IN ,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.例如:1. SELECT …2. FROM EMP3. WHERE DEPT_NO NOT IN (SELECT DEPT_NO4. FROM DEPT5. WHERE DEPT_CAT='A');为了提⾼效率.改写为:(⽅法⼀: ⾼效)1. SELECT ….2. FROM EMP A,DEPT B3. WHERE A.DEPT_NO = B.DEPT(+)4. AND B.DEPT_NO IS NULL5. AND B.DEPT_CAT(+) = 'A'(⽅法⼆: 最⾼效)1. SELECT ….2. FROM EMP E3. WHERE NOT EXISTS (SELECT 'X'4. FROM DEPT D5. WHERE D.DEPT_NO = E.DEPT_NO6. AND DEPT_CAT = 'A');当然,最⾼效率的⽅法是有表关联.直接两表关系对联的速度是最快的!11.识别'低效执⾏'的SQL语句⽤下列SQL⼯具找出低效SQL:1. SELECT EXECUTIONS , DISK_READS, BUFFER_GETS,2. ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,3. ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,4. SQL_TEXT5. FROM V$SQLAREA6. WHERE EXECUTIONS>07. AND BUFFER_GETS > 08. AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.89. ORDER BY 4 DESC;(虽然⽬前各种关于SQL优化的图形化⼯具层出不穷,但是写出⾃⼰的SQL⼯具来解决问题始终是⼀个最好的⽅法)关于SQL Server多表查询优化⽅案的相关知识就介绍到这⾥了，希望本次的介绍能够对您有所收获！。