第一篇：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（選擇性）
點擊咨詢 