第一篇：Java程序性能调优的基本知识和JDK调优
一 基本知识
1.1 性能是什么
在性能调优之前，我们首先来了解一下性能是什么？关于性能，我想每个学习过Java的人都能列出几点，甚至可以夸夸其谈。在《Java TM Platform Performance》一书中，定义了如下五个方面来作为评判性能的标准：
1)运算的性能——哪一个算法的执行性能最好？
2)内存的分配——程序运行时需要耗费多少内存？
3)启动的时间——程序启动需要多长时间？这在Web项目中的影响不大，但要注意部分程序需要部署或运行在客户端时的情形（比如applet程序）。
4)程序的可伸缩性——在压力负载的情况下，程序的性能如何？
5)性能的感知——用户在什么情况下会觉得程序的性能不好？
以上五个方面，在具体的使用场景可以有选择的去评判。至于这五方面的性能调优，在后续的章节中将会陆续的给以相应的性能调优策略。
1.2 调优的规则
我们只需要关心对我们程序有影响，可以察觉到的性能问题，而不是每一个类中的每一个方法我们都需要想方设法的提高性能。如果程序的性能没有达到我们所期 望的要求，我们才需要考虑如何优化性能。同样的，晦涩的代码虽然提高了程序的性能，但同时可能带给我们的是维护的噩梦。我们需要折中的考虑以上两种情况，使得程序的代码是优美的，并且运行的足够快，达到客户所期望的性能要求。
优化代码甚至会导致不良的结果，Donald Knuth（一位比较牛比较有影响的人物，具体是谁，我也忘了，谁知道，可以告诉我一下，谢谢！）曾说过，“Premature optimization is the root of all evil”。在开始性能调优前，需要先指出不优化代码的一些理由。
1)如果优化的代码已经正常工作，优化后可能会引入新的bug；
2)优化代码趋向于使代码更难理解和维护；
3)在一个平台上优化的代码，在另一个平台上可能更糟；
4)花费很多时间在代码的优化上，提高了很少的性能，却导致了晦涩的代码。确实，在优化前，我们必须认真的考虑是否值得去优化。
1.3 调优的步骤
一般我们提高应用程序的性能划分为以下几个步骤：
1)明确应用程序的性能指标，怎样才符合期望的性能需求；
2)在目标平台进行测试；
3)如果性能已经达到性能指标，Stop；
4)查找性能瓶颈；
5)修改性能瓶颈；
6)返回到第2步。
二 JDK调优
2.1 选择合适的JDK版本
不同版本的JDK，甚至不同厂家的JDK可能都存在着很大的差异，对于性能优化的程度不同。一般来说，尽可能选择最新发布的稳定的JDK版本。最新的稳定的JDK版本相对以前的JDK版本都会做一些bug的修改和性能的优化工作。
2.2 垃圾收集Java堆的优化
垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被后续的新对象所使用。垃圾收集 器必须能够断定哪些对象是不再被引用的，并且能够把它们所占据的堆空间释放出来。如果对象不再被使用，但还有被程序所引用，这时是不能被垃圾收集器所回收 的，此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏，有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具，使用它来 观察程序运行期的内存变化，并可产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到源码内。这个工具的使用我在后续的章节中还会做具体介 绍。
Java堆是指在程序运行时分配给对象生存的空间。通过-mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大堆的大小。根据自己JDK的版本和厂家决定使用-mx和-ms或-Xmx和-Xms。Java堆大小决定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越 低，速度越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置比较理想的参数，还是需要了解一些基础知识的。Java堆的最大值不能太大，这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太 大，造成垃圾回收的时间过长，这样将得不偿失，极大的影响程序的性能。以下是一些经常使用的参数设置：
1)设置-Xms等于-XmX的值；
2)估计内存中存活对象所占的空间的大小，设置-Xms等于此值，-Xmx四倍于此值；
3)设置-Xms等于-Xmx的1/2大小；
4)设置-Xms介于-Xmx的1/10到1/4之间；
5)使用默认的设置。
大家需要根据自己的运行程序的具体使用场景，来确定最适合自己的参数设置。除了-Xms和-Xmx两个最重要的参数外，还有很多可能会用到的参数，这些参数通常强烈的依赖于垃圾收集的算法，所以可能因为JDK的版本和厂家而有所 不同。但这些参数一般在Web开发中用的比较少，我就不做详细介绍了。在实际的应用中注意设置-Xms和-Xmx使其尽可能的优化应用程序就行了。对于性 能要求很高的程序，就需要自己再多研究研究Java虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入Java虚拟机》一书。
第二篇：Oracle性能调优实践中的几点心得
很多的时侯，做Oracle DBA的我们，当应用管理员向我们通告现在应用很慢、数据库很慢的时侯，我们到数据库时做几个示例的Select也发现同样的问题时，有些时侯我们会无从下手，因为我们认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在IO，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法，下面把我的一点实践经验与大家分享一下，本文测重于Unix环境。
一、通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。
1、如何检查操作系统是否存在IO的问题？使用的工具有sar,这是一个比较通用的工具。
Rp1#Sar-u 2 10 即每隔2秒检察一次，共执行20次，当然这些都由你决定了。
示例返回：
HP-UX hpn2 B.11.00 U 9000/800 08/05/03 18:26:32 %usr %sys %wio %idle 18:26:34 80 9 12 0 18:26:36 78 11 11 0 18:26:38 78 9 13 1 18:26:40 81 10 9 1 18:26:42 75 10 14 0 18:26:44 76 8 15 0 18:26:46 80 9 10 1 18:26:48 78 11 11 0 18:26:50 79 10 10 0 18:26:52 81 10 9 0 Average 79 10 11 0 其中的%usr指的是用户进程使用的cpu资源的百分比，%sys指的是系统资源使用cpu资源的百分比，%wio指的是等待io完成的百分比，这是值得我们观注的一项，%idle即空闲的百分比。如果wio列的值很大，如在35%以上，说明你的系统的IO存在瓶颈，你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例，可以看到wio平均值为11说明io没什么特别的问题，而我的idle值为零，说明我的cpu已经满负荷运行了。
当你的系统存在IO的问题，可以从以下几个方面解决
♀联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。
♀查找Oracle中不合理的sql语句，对其进行优化
♀对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
2、关注一下内存。
常用的工具便是vmstat，对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstat中pi列非零，memory中的free列的值很小，glance,topas中内存的利用率多于80%时，这时说明你的内存方面应该调节一下了，方法大体有以下几项。
♀划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。
♀为系统增加内存
♀如果你的连接特别多，可以使用MTS的方式
♀打全补丁，防止内存漏洞。
3、如何找到点用系用资源特别大的Oracle的session及其执行的语句。Hp-unix可以用glance,top IBM AIX可以用topas 些外可以使用ps的命令。
通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号，我们就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer,toad等软件中执行, 把<>中的spid换成你的spid就可以了。SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status, c.piece, c.sql_text FROM v$session a, v$process b, v$sqltext c WHERE b.spid=
AND b.addr=a.paddr AND a.sql_address=c.address(+)ORDER BY c.piece
我们就可以把得到的这个sql分析一下，看一下它的执行计划是否走索引，对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。
提示：我在做优化sql时，经常碰到使用in的语句，这时我们一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。比如：
SELECT col1,col2,col3 FROM table1 a
WHERE a.col1 not in(SELECT col1 FROM table2)可以换成：
SELECT col1,col2,col3 FROM table1 a WHERE not exists(SELECT 'x' FROM table2 b WHERE a.col1=b.col1)
4、另一个有用的脚本：查找前十条性能差的sql.SELECT * FROM
(SELECT PARSING_USER_ID EXECUTIONS, SORTS, COMMAND_TYPE, DISK_READS, sql_text FROM v$sqlarea ORDER BY disk_reads DESC)
WHERE ROWNUM<10;
二、迅速发现Oracle Server的性能问题的成因，我们可以求助于v$session_wait这个视图，看系统的这些session在等什么，使用了多少的IO。以下是我提供的参考脚本：
脚本说明：查看占io较大的正在运行的session SELECT se.sid, se.serial#, pr.SPID, se.username, se.status, se.terminal, se.program, se.MODULE, se.sql_address, st.event, st.p1text, si.physical_reads, si.block_changes
FROM v$session se, v$session_wait st, v$sess_io si, v$process pr WHERE st.sid=se.sid
AND st.sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.wait_time=0
AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC 对检索出的结果的几点说明：
1、我是按每个正在等待的session已经发生的物理读排的序，因为它与实际的IO相关。
2、你可以看一下这些等待的进程都在忙什么，语句是否合理？
Select sql_address from v$session where sid=
你也以用alter system kill session 'sid,serial#';把这个session杀掉。
3、应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说明： a、buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下： a.1增加写进程，同时要调整db_block_lru_latches参数 示例：修改或添加如下两个参数
db_writer_processes=4 db_block_lru_latches=8 a.2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
d、latch free,与栓相关的了，需要专门调节。
e、其他参数可以不特别观注。
结篇：匆忙之中写下了这篇文章，希望能抛砖引玉，能为你的Oracle调优实践带来帮助。
第三篇：性能调优JDK5.0自带工具
简介：
JDK 5.0, 代号老虎，在以往的Java传统上加入了许多新的设计，给Java语言带来了一些较大的变化，比如泛型，元数据，可变个数参数，静态导入类，新线程架构，自动装箱/拆箱等等新的以往没有的新特性。同时，在调试程序和解决性能各种问题方面，JDK5.0同样加入了多个分析工具来让开发者更加方便地调试他们自 己的程序，它们包括了命令行调试工具，图形界面调试工具等等.JDK5.0包括的调试工具：
我们在这里对JDK5.0的调试工具做大致的概念性的介绍，然后希望通过介绍我自己在实际工作中使用这些工具解决问题的实例来让大家对这些工具有更深入的了解。
JDK5.0里面加入了jstack, jconsole, jinfo, jmap, jdb, jstat, jps, 下面对这些工具做简单介绍：
jstack--如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到 当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。目前只有在Solaris和Linux的JDK版本里面才有。
jconsole – jconsole是基于Java Management Extensions(JMX)的实时图形化监测工具，这个工具利用了内建到JVM里面的JMX指令来提供实时的性能和资源的监控，包括了Java程序的内存使用，Heap size, 线程的状态，类的分配状态和空间使用等等。
jinfo – jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息，目前只有在Solaris和Linux的JDK版本里面才有。jmap – jmap 可以从core文件或进程中获得内存的具体匹配情况，包括Heap size, Perm size等等，目前只有在Solaris和Linux的JDK版本里面才有。
jdb – jdb 用来对core文件和正在运行的Java进程进行实时地调试，里面包含了丰富的命令帮助您进行调试，它的功能和Sun studio里面所带的dbx非常相似，但 jdb是专门用来针对Java应用程序的。
jstat – jstat利用了JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控等等。jps – jps是用来查看JVM里面所有进程的具体状态, 包括进程ID，进程启动的路径等等。另外，还有些其他附带的工具在这里没有列出，比如Heap Analysis Tool, kill-3 方法等等，这些在JDK5.0之前就有，同样也是非常有用的性能调优工具，大家可以参照相应的文档资料来学习，在文章后面也会推荐一些相应的文档给大家作为参考。好，说了这么多，让我们来看看JDK5.0自带的这些工具在现实工作能给我们带来什么帮助，下面是我和ISV一起共同工作的实际例子，在这里把它们简单阐述出来，希望对大家有所帮助。 jconsole和jstack使用实例：
在做过的项目中，曾经有几个是使用jstack和jconsole来解决问题的。在下面的例子中，由于部分代码涉及到公司名字，我使用了xxx来代替。
1.其中的一个是Web2.0的客户，由于目前Sun Microsystem公司推出的Niagara服务器系列非常适合网络方面的多线程应用，并且已经在业界非常出名，所以他们决定使用T2000服务器来测试一下如果应用到他们自己的应用是否能够获得出众的性能。
整个应用的架构如下：
Apache 2.0.59 + Resin EE 2.1.17 + Jdk 1.5.0.07 + Oracle 9 运行的操作系统: Solaris 10 Update 3(11/06), EIS patches包.测试工具：
Apache benchmark tool.在客户的测试环境中，我们分别做了Apache, Resin, Solaris的相应调整，其中包括了Apache使用Prefork模式，并且调整了httpd.conf文件里面相应的ServerLimit, ListenBacklog,Maxclient等等值，Resin服务器调整Jvm heap size, 并行回收new generation和old generation, 最大线程数，oracle连接数等等参数，Solaris操作系统做了网络和系统的相应调整，最终把整套系统搬进了生产环境，一切顺利进行，但当进入其中 的一个论坛系统时却发现系统响应时间非常缓慢，用Apache Benchmark Tool加少量压力得到结果如下，由于是在生产环境下所以不敢使用大的压力：
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0 Copyright(c)1996 Adam Twiss, Zeus Technology Ltd, http:// http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html http://java.sun.com/docs/hotspot/gc5.0/ergo5.html#0.0.Behavior%20based%20tuning%7Coutline http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html http://java.sun.com/ http://www.java.net/
第四篇：Oracle性能调优实践中的几点心得
Oracle性能调优实践中的几点心得
很多的时侯，做Oracle DBA的我们，当应用管理员向我们通告现在应用很慢、数据库很慢的时侯，我们到数据库时做几个示例的Select也发现同样的问题时，有些时侯我们会无从下手，因为我们认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在IO，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法，下面把我的一点实践经验与大家分享一下，本文测重于Unix环境。
一、通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。
1、如何检查操作系统是否存在IO的问题？使用的工具有sar,这是一个比较通用的工具。Rp1#Sar-u 2 10 即每隔2秒检察一次，共执行20次，当然这些都由你决定了。
示例返回：
HP-UX hpn2 B.11.00 U 9000/800 08/05/03 18:26:32 %usr %sys %wio %idle 18:26:34 80 9 12 0 18:26:36 78 11 11 0 18:26:38 78 9 13 1 18:26:40 81 10 9 1 18:26:42 75 10 14 0 18:26:44 76 8 15 0 18:26:46 80 9 10 1 18:26:48 78 11 11 0 18:26:50 79 10 10 0 18:26:52 81 10 9 0 Average 79 10 11 0 其中的%usr指的是用户进程使用的cpu资源的百分比，%sys指的是系统资源使用cpu资源的百分比，%wio指的是等待io完成的百分比，这是值得我们观注的一项，%idle即空闲的百分比。如果wio列的值很大，如在35%以上，说明你的系统的IO存在瓶颈，你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例，可以看到wio平均值为11说明io没什么特别的问题，而我的idle值为零，说明我的cpu已经满负荷运行了。当你的系统存在IO的问题，可以从以下几个方面解决
♀联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。
♀查找Oracle中不合理的sql语句，对其进行优化 ♀对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
2、关注一下内存。
常用的工具便是vmstat，对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstat中pi列非零，memory中的free列的值很小，glance,topas中内存的利用率多于80%时，这时说明你的内存方面应该调节一下了，方法大体有以下几项。
♀划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。
♀为系统增加内存
♀如果你的连接特别多，可以使用MTS的方式
♀打全补丁，防止内存漏洞。
3、如何找到点用系用资源特别大的Oracle的session及其执行的语句。Hp-unix可以用glance,top IBM AIX可以用topas 些外可以使用ps的命令。
通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号，我们就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer,toad等软件中执行, 把<>中的spid换成你的spid就可以了。SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status, c.piece, c.sql_text FROM v$session a, v$process b, v$sqltext c WHERE b.spid=
提示：我在做优化sql时，经常碰到使用in的语句，这时我们一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。比如：
SELECT col1,col2,col3 FROM table1 a WHERE a.col1 not in(SELECT col1 FROM table2)可以换成：
SELECT col1,col2,col3 FROM table1 a WHERE not exists(SELECT 'x' FROM table2 b WHERE a.col1=b.col1)
4、另一个有用的脚本：查找前十条性能差的sql.SELECT * FROM(SELECT PARSING_USER_ID EXECUTIONS, SORTS, COMMAND_TYPE, DISK_READS, sql_text FROM v$sqlarea ORDER BY disk_reads DESC)WHERE ROWNUM<10;
二、迅速发现Oracle Server的性能问题的成因，我们可以求助于v$session_wait这个视图，看系统的这些session在等什么，使用了多少的IO。以下是我提供的参考脚本： 脚本说明：查看占io较大的正在运行的session SELECT se.sid, se.serial#, pr.SPID, se.username, se.status, se.terminal, se.program, se.MODULE, se.sql_address, st.event, st.p1text, si.physical_reads, si.block_changes FROM v$session se, v$session_wait st, v$sess_io si, v$process pr WHERE st.sid=se.sid AND st.sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC 对检索出的结果的几点说明：
1、我是按每个正在等待的session已经发生的物理读排的序，因为它与实际的IO相关。
2、你可以看一下这些等待的进程都在忙什么，语句是否合理？ Select sql_address from v$session where sid=
你也以用alter system kill session 'sid,serial#';把这个session杀掉。
3、应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说明： a、buffer busy waits，free buffer waits 这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的
free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整； free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下： a.1增加写进程，同时要调整db_block_lru_latches参数
示例：修改或添加如下两个参数 db_writer_processes=4 db_block_lru_latches=8 a.2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。d、latch free,与栓相关的了，需要专门调节。e、其他参数可以不特别观注。
第五篇：SQL语句的调优
1.说明
数据库系统需要保存大量历史记录，系统内存在许多历史记录表，因此常常出现系统运行一段时间，表记录数达到一定数量后，系统响应明显变慢的现象。为尽可能的提高SQL执行的效率，我们在编写SQL语句应该遵循一定的优化规则，使代码风格统一、规范。充分利用表索引，避免进行全表扫描；充分利用结构化编程方式，提高查询的复用能力，也许完全遵守以下方法速度未必达到想要的结果，但是养成一个好的编程习惯是重要的。
2.调优方法
1)相同功能、性能的SQL语句
ORACLE采用共享内存SGA的机制，因此ORACLE会对每个不同写法的SQL进行分析，并且占用共享内存;如果书写格式完全相同，则ORACLE只分析一次，遇到相同书写格式的SQL，会直接从共享内存中获取结果集;这样便能减少共享池的开销以及代码的复用。
处理方法：保证书写格式相同，包括大小写，空格位置，表别名等一致；将一些通用的SQL语句作为公共函数由其它函数调用的方式使用。)动态SQL：动态SQL采用变量动态绑定的方式，避免重复解析。
3)连接方式与表名顺序
多表查询时需要选择最有效率的表名顺序（基于规则的优化器有效），ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名；因此写在最后的那张基础表最先被处理，即选择记录数最少的表作为基础表，首先,扫描FROM子句中最右的那个表，并对记录进行排序,然后扫描FROM子句中最后第二个表,最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。
4)查询条件顺序
ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理,表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件适合写在WHERE子句的末尾。
5)语法和语义
(1)SELECT子句中避免使用 ' * '
使用'*' ,Oracle便会查询数据字典，依次解析各列名，应明确指定各列的名称，这样也便于理解。
(2)使用表的别名(Alias)
多表查询时，使用表的别名，同样可以避免解析，避免歧义，提高效率。
6)函数和表达式
(1)用>=替代>
例如:DEPTNO上有一个索引,高效: SELECT * FROM EMP WHERE DEPTNO >=4
低效:SELECT * FROM EMP WHERE DEPTNO >3
两者的区别在于，前者DBMS将直接跳到第一个DEPT等于4的记录而后者将首先定位到DEPTNO=3的记录并且向前扫描到第一个DEPT大于3的记录.(2)使用DECODE函数来减少处理时间
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.(3)用TRUNCATE替代DELETE
当删除表中的记录时,在通常情况下，回滚段(rollback segments)用来存放可以被恢复的信息.如果你没有COMMIT事务，ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)，而当运用TRUNCATE时，回滚段不再存放任何可被恢复的信息.当命令运行后，数据不能被恢复，因此很少的资源被调用，执行时间也会很短。TRUNCATE只在删除全表或分区适用，TRUNCATE是DDL不是DML
7)常用关键字优先级
(1)用EXISTS替代IN
用IN将启用全表扫描，使用EXISTS将利用索引，提高查询效率。
(2)用NOT EXISTS替代NOT IN
用NOT IN将启用全表扫描，使用NOT EXISTS将利用索引，提高查询效率。
(3)用表连接替换EXISTS
(4)用EXISTS替换DISTINCT
(5)避免在索引列上使用IS NULL和IS NOT NULL
如果索引包含任何可以为空的列，ORACLE将无法使用该索引，举例如下：
低效(索引失效):
SELECT * FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效(索引有效): SELECT * FROM DEPARTMENT WHERE DEPT_CODE >=0;
(6)用UNION-ALL 替换UNION
当SQL语句需要UNION两个查询结果集合时，这两个结果集合会以UNION-ALL的方式被合并，然后在输出最终结果前进行排序。
如果用UNION ALL替代UNION，这样排序就不是必要了。效率就会因此得到提高。
(7)用UNION替换OR(适用于索引列)
通常情况下，用UNION替换WHERE子句中的OR将会起到较好的效果。对索引列使用OR将造成全表扫描。注意，以上规则只针对多个索引列有效。如果有column没有被索引，查询效率可能会因为你没有选择OR而降低。
(8)用WHERE替代ORDER BY
ORDER BY 子句只在两种严格的条件下使用索引: ORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序。ORDER BY中所有的列必须定义为非空。WHERE子句使用的索引和ORDER BY子句中所使用的索引不能并列.(9)用WHERE子句替换HAVING子句
避免使用HAVING子句，HAVING 只会在检索出所有记录之后才对结果集进行过滤。这个处理需要排序，总计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。例子如下:
低效:
SELECT REGION，AVG(LOG_SIZE)
FROM LOCATION
GROUP BY REGION
HAVING REGION REGION!= 'SYDNEY'AND REGION!= 'PERTH'
高效
SELECT REGION，AVG(LOG_SIZE)
FROM LOCATION
WHERE REGION REGION!= 'SYDNEY'
AND REGION!= 'PERTH'
GROUP BY REGION
HAVING 中的条件一般用于对一些集合函数的比较，如COUNT()等等。除此之外，一般的条件应该写在WHERE子句中。
(10)GROUP BY的使用
提高GROUP BY 语句的效率，可以通过将不需要的记录在GROUP BY 之前过滤掉。下面两个查询返回相同结果但第二个明显就快了许多。
(11)全局参数
8)其它因素
(1)减少访问数据库的次数
当执行每条SQL语句时，ORACLE在内部执行了许多工作:
解析SQL语句
估算索引的利用率
绑定变量
读数据块等等
由此可见, 减少访问数据库的次数 , 就能实际上减少ORACLE的工作量。
(2)常使用COMMIT
只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也会因为COMMIT所释放的资源而减少。COMMIT所释放的资源:
（1）回滚段上用于恢复数据的信息.（2）被程序语句获得的锁
（3）redo log buffer 中的空间
（4）ORACLE为管理上述3种资源中的内部花费
9)常见优化工具介绍
(1)用Explain Plan分析SQL语句
EXPLAIN PLAN 是一个很好的分析SQL语句的工具，它甚至可以在不执行SQL的情况下分析语句。通过分析，我们就可以知道ORACLE是怎么样连接表，使用什么方式扫描表(索引扫描或全表扫描)以及使用到的索引名称。
(2)SQL PLUS的TRACE
3.常用术语
1)全表扫描
全表扫描就是顺序地访问表中每条记录，ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描
2)通过索引访问（ROWID）
ROWID包含了表中记录的物理位置信息，ORACLE采用索引实现了数据和存放数据的物理位置(ROWID)之间的联系，通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。
3)共享SQL
（1）Oracle提供对执行过的SQL语句进行高速缓冲的机制。被解析过并且确定了执行路径的SQL语句存放在SGA的共享池中。
（2）Oracle执行一个SQL语句之前每次先从SGA共享池中查找是否有缓冲的SQL语句，如果有则直接执行该SQL语句。
（3）可以通过适当调整SGA共享池大小来达到提高Oracle执行性能的目的。
4)ORACLE优化器
（1）RULE（基于规则）
（2）COST（基于成本）
（3）CHOOSE（选择性）
点击咨询 