SQL語句優化進步數據庫機能

SQL語句優化進步數據庫機能。本站提示廣大學習愛好者：（SQL語句優化進步數據庫機能）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL語句優化進步數據庫機能正文

---

機能不睬想的體系中除一部門是由於運用法式的負載確切跨越了辦事器的現實處置才能外,更多的是由於體系存在年夜量的SQL語句須要優化。為了取得穩固的履行機能，SQL語句越簡略越好。對龐雜的SQL語句，要想法對之停止簡化。

罕見的簡化規矩以下：

1）不要有跨越5個以上的表銜接（JOIN）
2）斟酌應用暫時表或表變量寄存中央成果
3）罕用子查詢
4）視圖嵌套不要過深,普通視圖嵌套不要跨越2個為好

1、成績的提出

在運用體系開辟早期，因為開辟數據庫數據比擬少，關於查詢SQL語句，龐雜視圖的的編寫等領會不出SQL語句各類寫法的機能好壞，然則假如將運用體系提交現實運用後，跟著數據庫中數據的增長，體系的呼應速度就成為今朝體系須要處理的最重要的成績之一。體系優化中一個很主要的方面就是SQL語句的優化。關於海量數據，劣質SQL語句和優良SQL語句之間的速度差異可以到達上百倍，可見關於一個體系不是簡略地能完成其功效便可，而是要寫出高質量的SQL語句，進步體系的可用性。

在多半情形下，Oracle應用索引來更快地遍歷表，優化器重要依據界說的索引來進步機能。然則，假如在SQL語句的where子句中寫的SQL代碼不公道，就會形成優化器刪去索引而應用全表掃描，普通就這類SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清晰優化器依據何種准繩來刪除索引，這有助於寫出高機能的SQL語句。

2、SQL語句編寫留意成績

上面就某些SQL語句的where子句編寫中須要留意的成績作具體引見。在這些where子句中，即便某些列存在索引，然則因為編寫了劣質的SQL，體系在運轉該SQL語句時也不克不及應用該索引，而異樣應用全表掃描，這就形成了呼應速度的極年夜下降。

1. 操作符優化

(a) IN 操作符

用IN寫出來的SQL的長處是比擬輕易寫及清楚易懂，這比擬合適古代軟件開辟的作風。然則用IN的SQL機能老是比擬低的，從Oracle履行的步調來剖析用IN的SQL與不消IN的SQL有以下差別：

ORACLE試圖將其轉換成多個表的銜接，假如轉換不勝利則先履行IN外面的子查詢，再查詢外層的表記載，假如轉換勝利則直接采取多個表的銜接方法查詢。因而可知用IN的SQL至多多了一個轉換的進程。普通的SQL都可以轉換勝利，但關於含有分組統計等方面的SQL就不克不及轉換了。

推舉計劃：在營業密集的SQL傍邊盡可能不采取IN操作符，用EXISTS 計劃取代。

(b) NOT IN操作符

此操作是強列不推舉應用的，由於它不克不及運用表的索引。

推舉計劃：用NOT EXISTS 計劃取代

(c) IS NULL 或IS NOT NULL操作（斷定字段能否為空）

斷定字段能否為空普通是不會運用索引的，由於索引是不索引空值的。不克不及用null作索引，任何包括null值的列都將不會被包括在索引中。即便索引有多列如許的情形下，只需這些列中有一列含有null，該列就會從索引中消除。也就是說假如某列存在空值，即便對該列建索引也不會進步機能。任安在where子句中應用is null或is not null的語句優化器是不許可應用索引的。

推舉計劃：用其它雷同功效的操作運算取代，如：a is not null 改成 a>0 或a>''等。不許可字段為空，而用一個缺省值取代空值，如請求中狀況字段不許可為空，缺省為請求。

(d) > 及 < 操作符（年夜於或小於操作符）

年夜於或小於操作符普通情形下是不消調劑的，由於它有索引就會采取索引查找，但有的情形下可以對它停止優化，如一個表有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的記載索引。

(e) LIKE操作符

LIKE操作符可以運用通配符查詢，外面的通配符組合能夠到達簡直是隨意率性的查詢，然則假如用得欠好則會發生機能上的成績，如LIKE ‘%5400%' 這類查詢不會援用索引，而LIKE ‘X5400%'則會援用規模索引。

一個現實例子：用YW_YHJBQK表中營業編號前面的戶標識號可來查詢營業編號 YY_BH LIKE ‘%5400%' 這個前提會發生全表掃描，假如改成YY_BH LIKE 'X5400%' OR YY_BH LIKE 'B5400%' 則會應用YY_BH的索引停止兩個規模的查詢，機能確定年夜年夜進步。

帶通配符(%)的like語句：

異樣以下面的例子來看這類情形。今朝的需求是如許的，請求退職工表中查詢名字中包括cliton的人。可以采取以下的查詢SQL語句:

select * from employee where last_name like '%cliton%';

這裡因為通配符(%)在搜索詞首湧現，所以Oracle體系不應用last_name的索引。在許多情形下能夠沒法防止這類情形，然則必定要心中有底，通配符如斯應用會下降查詢速度。但是當通配符湧現在字符串其他地位時，優化器就可以應用索引。鄙人面的查詢中索引獲得了應用:

select * from employee where last_name like 'c%';

(f) 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

(g) 聯接列

關於有聯接的列，即便最初的聯接值為一個靜態值，優化器是不會應用索引的。我們一路來看一個例子，假定有一個職工表(employee)，關於一個職工的姓和名分紅兩列寄存(FIRST_NAME和LAST_NAME)，如今要查詢一個叫比爾.克林頓(Bill Cliton)的職工。

上面是一個采取聯接查詢的SQL語句：

select * from employss where first_name||''||last_name ='Beill Cliton';

下面這條語句完整可以查詢出能否有Bill Cliton這個員工，然則這裡須要留意，體系優化器對基於last_name創立的索引沒有應用。當采取上面這類SQL語句的編寫，Oracle體系便可以采取基於last_name創立的索引。

where first_name ='Beill' and last_name ='Cliton';

(h) Order by語句

ORDER BY語句決議了Oracle若何將前往的查詢成果排序。Order by語句對要排序的列沒有甚麼特殊的限制，也能夠將函數參加列中(象聯接或許附加等)。任安在Order by語句的非索引項或許有盤算表達式都將下降查詢速度。

細心檢討order by語句以找出非索引項或許表達式，它們會下降機能。處理這個成績的方法就是重寫order by語句以應用索引，也能夠為所應用的列樹立別的一個索引，同時應相對防止在order by子句中應用表達式。

(i) NOT

我們在查詢時常常在where子句應用一些邏輯表達式，如年夜於、小於、等於和不等於等等，也能夠應用and(與)、or(或)和not(非)。NOT可用來對任何邏輯運算符號取反。上面是一個NOT子句的例子:

where not (status ='VALID')

假如要應用NOT，則應在取反的短語後面加上括號，並在短語後面加上NOT運算符。NOT運算符包括在別的一個邏輯運算符中，這就是不等於(<>)運算符。換句話說，即便不在查詢where子句中顯式地參加NOT詞，NOT仍在運算符中，見下例:

where status <>'INVALID';

對這個查詢，可以改寫為不應用NOT：

select * from employee where salary<3000 or salary>3000;

固然這兩種查詢的成果一樣，然則第二種查詢計劃會比第一種查詢計劃更快些。第二種查詢許可Oracle對salary列應用索引，而第一種查詢則不克不及應用索引。

2. SQL書寫的影響

(a) 統一功效統一機能分歧寫法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的履行頻率。

(b) 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占用率顯著比第一條低。

(c) 查詢表次序的影響

在FROM前面的表中的列表次序會對SQL履行機能影響，在沒有索引及ORACLE沒有對表停止統計剖析的情形下，ORACLE會按表湧現的次序停止鏈接，因而可知表的次序纰謬時會發生非常耗服物器資本的數據穿插。（注：假如對表停止了統計剖析，ORACLE會主動先輩小表的鏈接，再停止年夜表的鏈接）

3. SQL語句索引的應用

(a) 對前提字段的一些優化

采取函數處置的字段不克不及應用索引，如：

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'

4. 更多方面SQL優化材料分享

（1） 選擇最有用率的表名次序(只在基於規矩的優化器中有用)：

ORACLE 的解析器依照從右到左的次序處置FROM子句中的表名，FROM子句中寫在最初的表(基本表 driving table)將被最早處置，在FROM子句中包括多個表的情形下,你必需選擇記載條數起碼的表作為基本表。假如有3個以上的表銜接查詢, 那就須要選擇穿插表(intersection table)作為基本表, 穿插表是指誰人被其他表所援用的表.

（2） WHERE子句中的銜接次序：

ORACLE采取自下而上的次序解析WHERE子句,依據這個道理,表之間的銜接必需寫在其他WHERE前提之前, 那些可以過濾失落最年夜數目記載的前提必需寫在WHERE子句的末尾.

（3） SELECT子句中防止應用 ‘ * ‘：

ORACLE在解析的進程中, 會將'*' 順次轉換成一切的列名, 這個任務是經由過程查詢數據字典完成的, 這意味著將消耗更多的時光。

（4） 削減拜訪數據庫的次數：

ORACLE在外部履行了很多任務: 解析SQL語句, 預算索引的應用率, 綁定變量 , 讀數據塊等。

（5） 在SQL*Plus , SQL*Forms和Pro*C中從新設置ARRAYSIZE參數, 可以增長每次數據庫拜訪的檢索數據量 ,建議值為200。

（6） 應用DECODE函數來削減處置時光：

應用DECODE函數可以免反復掃描雷同記載或反復銜接雷同的表.

（7） 整合簡略,有關聯的數據庫拜訪：

假如你有幾個簡略的數據庫查詢語句,你可以把它們整合到一個查詢中(即便它們之間沒有關系) 。

（8） 刪除反復記載：

最高效的刪除反復記載辦法 ( 由於應用了ROWID)例子：

DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO)。

（9） 用TRUNCATE替換DELETE：

當刪除表中的記載時,在平日情形下, 回滾段(rollback segments ) 用來寄存可以被恢復的信息. 假如你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀況(精確地說是恢復到履行刪除敕令之前的狀態) 而當應用TRUNCATE時, 回滾段不再寄存任何可被恢復的信息.當敕令運轉後,數據不克不及被恢復.是以很少的資本被挪用,履行時光也會很短. (譯者按: TRUNCATE只在刪除全表實用,TRUNCATE是DDL不是DML) 。

（10） 盡可能多應用COMMIT：

只需有能夠,在法式中盡可能多應用COMMIT, 如許法式的機能獲得進步,需求也會由於COMMIT所釋放的資本而削減，COMMIT所釋放的資本:

a. 回滾段上用於恢單數據的信息.
b. 被法式語句取得的鎖
c. redo log buffer 中的空間
d. ORACLE為治理上述3種資本中的外部消費

（11） 用Where子句調換HAVING子句：

防止應用HAVING子句, HAVING 只會在檢索出一切記載以後才對成果集停止過濾. 這個處置須要排序,總計等操作. 假如能經由過程WHERE子句限制記載的數量,那就可以削減這方面的開支. (非oracle中)on、where、having這三個都可以加前提的子句中，on是最早履行，where次之，having最初，由於on是先把不相符前提的記載過濾後才停止統計，它便可以削減中央運算要處置的數據，按理說應當速度是最快的，where也應當比having快點的，由於它過濾數據後才停止sum，在兩個表聯接時才用on的，所以在一個表的時刻，就剩下where跟having比擬了。在這單表查詢統計的情形下，假如要過濾的前提沒有觸及到要盤算字段，那它們的成果是一樣的，只是where可使用rushmore技巧，而having就不克不及，在速度上後者要慢假如要觸及到盤算的字 段，就表現在沒盤算之前，這個字段的值是不肯定的，依據上篇寫的任務流程，where的感化時光是在盤算之前就完成的，而having就是在盤算後才起作 用的，所以在這類情形下，二者的成果會分歧。在多表聯接查詢時，on比where更夙興感化。體系起首依據各個表之間的聯接前提，把多個表分解一個暫時表 後，再由where停止過濾，然後再盤算，盤算完後再由having停止過濾。因而可知，要想過濾前提起到准確的感化，起首要明確這個前提應當在甚麼時刻起感化，然後再決議放在那邊。

（12） 削減對表的查詢：

在含有子查詢的SQL語句中,要特殊留意削減對表的查詢.例子：

SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)

（13） 經由過程外部函數進步SQL效力：

龐雜的SQL常常就義了履行效力. 可以或許控制下面的應用函數處理成績的辦法在現實任務中長短常成心義的。

（14） 應用表的別號(Alias)：

當在SQL語句中銜接多個表時, 請應用表的別號並把別號前綴於每一個Column上.如許一來,便可以削減解析的時光並削減那些由Column歧義惹起的語法毛病。

（15） 用EXISTS替換IN、用NOT EXISTS替換NOT IN：

在很多基於基本表的查詢中,為了知足一個前提,常常須要對另外一個表停止聯接.在這類情形下, 應用EXISTS(或NOT EXISTS)平日將進步查詢的效力. 在子查詢中,NOT IN子句將履行一個外部的排序和歸並. 不管在哪一種情形下,NOT IN都是最低效的 (由於它對子查詢中的表履行了一個全表遍歷). 為了不應用NOT IN ,我們可以把它改寫成外銜接(Outer Joins)或NOT EXISTS。

例子：

（高效）SELECT * FROM EMP (基本表) WHERE EMPNO > 0 AND EXISTS (SELECT ‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB') 
(低效)SELECT * FROM EMP (基本表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB')

（16） 辨認'低效履行'的SQL語句：

固然今朝各類關於SQL優化的圖形化對象層見疊出,然則寫出本身的SQL對象來處理成績一直是一個最好的辦法：

SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, 
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio, 
ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run, 
SQL_TEXT 
FROM V$SQLAREA 
WHERE EXECUTIONS>0 
AND BUFFER_GETS > 0 
AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 
ORDER BY 4 DESC;

（17） 用索引進步效力：

索引是表的一個概念部門,用來進步檢索數據的效力，ORACLE應用了一個龐雜的自均衡B-tree構造. 平日,經由過程索引查詢數據比全表掃描要快. 當ORACLE找出履行查詢和Update語句的最好途徑時, ORACLE優化器將應用索引. 異樣在聯絡多個表時應用索引也能夠進步效力. 另外一個應用索引的利益是,它供給了主鍵(primary key)的獨一性驗證.。那些LONG或LONG RAW數據類型, 你可以索引簡直一切的列. 平日, 在年夜型表中應用索引特殊有用. 固然,你也會發明, 在掃描小表時,應用索引異樣能進步效力. 固然應用索引能獲得查詢效力的進步,然則我們也必需留意到它的價值. 索引須要空間來存儲,也須要按期保護, 每當有記載在表中增減或索引列被修正時, 索引自己也會被修正. 這意味著每筆記錄的INSERT , DELETE , UPDATE將為此多支付4 , 5 次的磁盤I/O . 由於索引須要額定的存儲空間和處置,那些不用要的索引反而會使查詢反響時光變慢.。按期的重構索引是有需要的：

ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>

（18） 用EXISTS調換DISTINCT：

當提交一個包括一對多表信息(好比部分表和雇員表)的查詢時,防止在SELECT子句中應用DISTINCT. 普通可以斟酌用EXIST調換, EXISTS 使查詢更加敏捷,由於RDBMS焦點模塊將在子查詢的前提一旦知足後,連忙前往成果. 例子：

(低效): 
SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO 
(高效): 
SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);

（19） sql語句用年夜寫的；由於oracle老是先解析sql語句，把小寫的字母轉換成年夜寫的再履行。

（20） 在java代碼中盡可能罕用銜接符“＋”銜接字符串！

（21） 防止在索引列上應用NOT，平日我們要防止在索引列上應用NOT, NOT會發生在和在索引列上應用函數雷同的影響. 當ORACLE”碰到”NOT,他就會停滯應用索引轉而履行全表掃描。

（22） 防止在索引列上應用盤算

WHERE子句中，假如索引列是函數的一部門．優化器將不應用索引而應用全表掃描．舉例:

低效： 
SELECT … FROM DEPT WHERE SAL * 12 > 25000; 
高效: 
SELECT … FROM DEPT WHERE SAL > 25000/12;
（23） 用>=替換>
高效: 
SELECT * FROM EMP WHERE DEPTNO >=4 
低效: 
SELECT * FROM EMP WHERE DEPTNO >3

二者的差別在於, 前者DBMS將直接跳到第一個DEPT等於4的記載爾後者將起首定位到DEPTNO=3的記載而且向前掃描到第一個DEPT年夜於3的記載。

（24） 用UNION調換OR (實用於索引列)

平日情形下, 用UNION調換WHERE子句中的OR將會起到較好的後果. 對索引列應用OR將形成全表掃描. 留意, 以上規矩只針對多個索引列有用. 假如有column沒有被索引, 查詢效力能夠會由於你沒有選擇OR而下降. 鄙人面的例子中, LOC_ID 和REGION上都建有索引.

高效: 
SELECT LOC_ID , LOC_DESC , REGION 
FROM LOCATION 
WHERE LOC_ID = 10 
UNION 
SELECT LOC_ID , LOC_DESC , REGION 
FROM LOCATION 
WHERE REGION = “MELBOURNE” 
低效: 
SELECT LOC_ID , LOC_DESC , REGION 
FROM LOCATION 
WHERE LOC_ID = 10 OR REGION = “MELBOURNE”

假如你保持要用OR, 那就須要前往記載起碼的索引列寫在最後面.

（25） 用IN來調換OR

這是一條簡略易記的規矩，然則現實的履行後果還須磨練，在ORACLE8i下，二者的履行途徑仿佛是雷同的．

低效: 
SELECT…. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30 
高效 
SELECT… FROM LOCATION WHERE LOC_IN IN (10,20,30);

（26） 防止在索引列上應用IS NULL和IS NOT NULL

防止在索引中應用任何可認為空的列，ORACLE將沒法應用該索引．關於單列索引，假如列包括空值，索引中將不存在此記載. 關於復合索引，假如每一個列都為空，索引中異樣不存在此記載. 假如至多有一個列不為空，則記載存在於索引中．舉例: 假如獨一性索引樹立在表的A列和B列上, 而且表中存在一筆記錄的A,B值為(123,null) , ORACLE將不接收下一條具有雷同A,B值（123,null）的記載(拔出). 但是假如一切的索引列都為空，ORACLE將以為全部鍵值為空而空不等於空. 是以你可以拔出1000 條具有雷同鍵值的記載,固然它們都是空! 由於空值不存在於索引列中,所以WHERE子句中對索引列停止空值比擬將使ORACLE停用該索引.

低效: (索引掉效) 
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL; 
高效: (索引有用) 
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;

（27） 老是應用索引的第一個列：

假如索引是樹立在多個列上, 只要在它的第一個列(leading column)被where子句援用時,優化器才會選擇應用該索引. 這也是一條簡略而主要的規矩，當僅援用索引的第二個列時,優化器應用了全表掃描而疏忽了索引。

（28） 用UNION-ALL 調換UNION ( 假如有能夠的話)：

當SQL 語句須要UNION兩個查詢成果聚集時,這兩個成果聚集會以UNION-ALL的方法被歸並, 然後在輸入終究成果進步行排序. 假如用UNION ALL替換UNION, 如許排序就不是需要了. 效力就會是以獲得進步. 須要留意的是，UNION ALL 將反復輸入兩個成果聚集中雷同記載. 是以列位照樣要從營業需求剖析應用UNION ALL的可行性. UNION 將對成果聚集排序,這個操作會應用到SORT_AREA_SIZE這塊內存. 關於這塊內存的優化也是相當主要的. 上面的SQL可以用來查詢排序的消費量

低效：
SELECT ACCT_NUM, BALANCE_AMT 
FROM DEBIT_TRANSACTIONS 
WHERE TRAN_DATE = '31-DEC-95' 
UNION 
SELECT ACCT_NUM, BALANCE_AMT 
FROM DEBIT_TRANSACTIONS 
WHERE TRAN_DATE = '31-DEC-95' 
高效: 
SELECT ACCT_NUM, BALANCE_AMT 
FROM DEBIT_TRANSACTIONS 
WHERE TRAN_DATE = '31-DEC-95' 
UNION ALL 
SELECT ACCT_NUM, BALANCE_AMT 
FROM DEBIT_TRANSACTIONS 
WHERE TRAN_DATE = '31-DEC-95'

（29） 用WHERE替換ORDER BY：

ORDER BY 子句只在兩種嚴厲的前提下應用索引.
ORDER BY中一切的列必需包括在雷同的索引中並堅持在索引中的分列次序.
ORDER BY中一切的列必需界說為非空.
WHERE子句應用的索引和ORDER BY子句中所應用的索引不克不及並列.

例如:

表DEPT包括以以下:

DEPT_CODE PK NOT NULL
DEPT_DESC NOT NULL
DEPT_TYPE NULL

低效: (索引不被應用) 
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE 
高效: (應用索引) 
SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0

（30） 防止轉變索引列的類型:

當比擬分歧數據類型的數據時, ORACLE主動對列停止簡略的類型轉換.
假定 EMPNO是一個數值類型的索引列.

SELECT … FROM EMP WHERE EMPNO = ‘123'

現實上,經由ORACLE類型轉換, 語句轉化為:

SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123')

榮幸的是,類型轉換沒有產生在索引列上,索引的用處沒有被轉變.
如今,假定EMP_TYPE是一個字符類型的索引列.

SELECT … FROM EMP WHERE EMP_TYPE = 123

這個語句被ORACLE轉換為:

SELECT … FROM EMP WHERE TO_NUMBER(EMP_TYPE)=123

由於外部產生的類型轉換, 這個索引將不會被用到! 為了不ORACLE對你的SQL停止隱式的類型轉換, 最好把類型轉換用顯式表示出來. 留意當字符和數值比擬時, ORACLE會優先轉換數值類型到字符類型。

剖析

select emp_name form employee where salary > 3000

在此語句中若salary是Float類型的，則優化器對其停止優化為Convert(float,3000)，由於3000是個整數，我們應在編程時應用3000.0而不要等運轉時讓DBMS停止轉化。異樣字符和整型數據的轉換。

（31） 須要小心的WHERE子句:

某些SELECT 語句中的WHERE子句不應用索引. 這裡有一些例子.
鄙人面的例子裡, (1)‘!=' 將不應用索引. 記住, 索引只能告知你甚麼存在於表中, 而不克不及告知你甚麼不存在於表中. (2) ‘ ¦ ¦'是字符銜接函數. 就象其他函數那樣, 停用了索引. (3) ‘+'是數學函數. 就象其他數學函數那樣, 停用了索引. (4)雷同的索引列不克不及相互比擬,這將會啟用全表掃描.

（32） a. 假如檢索數據量跨越30%的表中記載數.應用索引將沒有明顯的效力進步. b. 在特定情形下, 應用索引或許會比全表掃描慢, 但這是統一個數目級上的差別. 而平日情形下,應用索引比全表掃描要塊幾倍甚至幾千倍!

（33） 防止應用消耗資本的操作：

帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎履行消耗資本的排序(SORT)功效. DISTINCT須要一次排序操作, 而其他的至多須要履行兩次排序. 平日, 帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方法重寫. 假如你的數據庫的SORT_AREA_SIZE分配得好, 應用UNION , MINUS, INTERSECT也是可以斟酌的, 究竟它們的可讀性很強。

（34） 優化GROUP BY：

進步GROUP BY 語句的效力, 可以經由過程將不須要的記載在GROUP BY 之前過濾失落.上面兩個查詢前往雷同成果但第二個顯著就快了很多.

低效: 
SELECT JOB , AVG(SAL) 
FROM EMP 
GROUP by JOB 
HAVING JOB = ‘PRESIDENT' 
OR JOB = ‘MANAGER' 
高效: 
SELECT JOB , AVG(SAL) 
FROM EMP 
WHERE JOB = ‘PRESIDENT' 
OR JOB = ‘MANAGER' 
GROUP by JOB