Ⅰ 如何優化sql語句
一、問題的提出
在應用系統開發初期，由於開發資料庫數據比較少，對於查詢SQL語句，復雜視圖的的編寫等體會不出SQL語句各種寫法的性能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中數據的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於海量數據，劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍，可見對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提高系統的可用性。
在多數情況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提高性能。但是，如果在SQL語句的where子句中寫的SQL代碼不合理，就會造成優化器刪去索引而使用全表掃描，一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清楚優化器根據何種原則來刪除索引，這有助於寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中，即使某些列存在索引，但是由於編寫了劣質的SQL，系統在運行該SQL語句時也不能使用該索引，而同樣使用全表掃描，這就造成了響應速度的極大降低。
1.
IS
NULL
與
IS
NOT
NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。
任何在where子句中使用is
null或is
not
null的語句優化器是不允許使用索引的。
2.
聯接列
對於有聯接的列，即使最後的聯接值為一個靜態值，優化器是不會使用索引的。我們一起來看一個例子，假定有一個職工表(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';
.
帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的，要求在職工表中查詢名字中包含cliton的人。可以採用如下的查詢SQL語句:
select
*
from
employee
where
last_name
like
'%cliton%';
這里由於通配符(%)在搜尋詞首出現，所以Oracle系統不使用last_name的索引。在很多情況下可能無法避免這種情況，但是一定要心中有底，通配符如此使用會降低查詢速度。然而當通配符出現在字元串其他位置時，優化器就能利用索引。在下面的查詢中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by語句
ORDER
BY語句決定了Oracle如何將返回的查詢結果排序。Order
by語句對要排序的列沒有什麼特別的限制，也可以將函數加入列中(象聯接或者附加等)。任何在Order
by語句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order
by語句以找出非索引項或者表達式，它們會降低性能。解決這個問題的辦法就是重寫order
by語句以使用索引，也可以為所使用的列建立另外一個索引，同時應絕對避免在order
by子句中使用表達式。
5.
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列使用索引，而第一種查詢則不能使用索引。
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
Ⅱ 求SQL資料庫論文
ORACLE中SQL查詢優化研究
摘 要 資料庫性能問題一直是決策者及技術人員共同關注的焦點，影響資料庫性能的一個重要因素就是SQL查詢語句的低效率。論文首先分析了導致SQL查詢語句性能低下的四個常見原因以及SQL調優的一般步驟，然後分別針對如何降低I/O操作、在查詢語句中如何避免對查詢結果的高成本操作以及在多表連接時如何提高查詢效率進行了分析。
關鍵詞 ORACLE；SQL；優化；連接
1 引言
隨著網路應用不斷發展，系統性能已越來越引起決策者的重視。影響系統性能的因素很多，低效的SQL語句就是其中一個不可忽視的重要原因。論文首先分析導致SQL性能低下的常見原因，然後分析SQL調優應遵循的一般步驟，最後從如何降低I/O、避免對查詢結果的高成本操作和多表連接中如何提高SQL性能進行了研究。鑒於目前ORACLE在資料庫市場上的主導地位，論文將只針對ORACLE進行討論。
2 影響SQL性能的原因
影響SQL性能的因素很多，如初始化參數設置不合理、導入了不準確的系統及模式統計數據從而影響優化程序(CBO)的正確判斷等，這些往往和DBA密切相關。純粹從SQL語句出發，筆者認為影響SQL性能不外乎以下四個重要原因：
(1)在大記錄集上進行高成本操作，如使用了引起排序的謂詞等。
(2)過多的I/O操作(含物理I/O與邏輯I/O)，最典型的就是未建立恰當的索引，導致對查詢表進行全表掃描。
(3)處理了太多的無用記錄，如在多表連接時過濾條件位置不當導致中間結果集包含了太多的無用記錄。
(4)未充分利用資料庫提供的功能，如查詢的並行化處理等。
第(4)個原因處理起來相對簡單。論文將針對前三個原因論述如何提高SQL查詢語句的性能。
3 SQL優化的一般步驟
SQL優化一般需經過發現問題、分析問題、提出解決措施、應用措施、測試性能幾個步驟，如圖1所示。「發現問題就是解決問題的一半」，因此在SQL調優過程中，定位問題SQL是非常重要的一步，一般可藉助於ORACLE自帶的性能優化工具如STATSPACK、TKPROF、AUTOTRACE等輔助用戶進行，同時還應該重視動態性能視圖如V$SQL、V$MYSTAT、V$SYSSTAT等的研究。
圖1 SQL優化的一般步驟
4 SQL語句的優化
4.1 優化排序操作
排序的成本十分高昂，當在查詢語句中使用了引起結果集排序的謂詞時，SQL性能必然受到影響。
4.1.1 排序過程分析
當待排序數據集不是太大時，伺服器在內存(排序區)完成排序操作，如果排序需要更多的內存空間，伺服器將進行如下處理：
(1) 將數據分成多個小的集合，對每一集合進行排序。
(2) 伺服器向磁碟申請臨時空間，將排好序的中間結果寫入臨時段，再對另外的集合進行排序。
(3) 在所有的集合均排好序後，伺服器再將它們進行合並得到最終的結果，如果排序區尺寸太小，合並無法一次完成時，將分多次進行。
從上述分析可知，排序是一種十分昂貴的操作，它消耗大量的CPU時間和內存，觸發磁碟分頁和交換操作，因此只要有可能，我們就應該在SQL語句中盡量避免排序操作。
4.1.2 SQL中引起排序的操作
SQL查詢語句中引起排序的操作大致有：ORDER BY 和GROUP BY 從句；DISTINCT修飾符；UNION、INTERSECT、MINUS集合操作符；多表連接時的排序合並連接(SORT MERGE JOIN)等。
4.1.3 如何避免排序
1)建立恰當的索引
對經常進行排序和連接操作的欄位建立索引。在建立索引後，當伺服器向這些欄位發出排序請求時，將直接引用索引而不進行排序操作；當進行等值連接查詢操作時，若建立連接的欄位未建立索引，伺服器進行的是排序合並連接(SORT MERGE JOIN)，連接操作的過程如下：
對進行連接的兩個或多個表分別進行全掃描；
對每一個表中的行集分別進行全排序；
合並排序結果。
如果建立連接的欄位已建立索引，伺服器進行嵌套循環連接(NESTED LOOP JOINS)，該連接方式不需要任何排序，其過程如下：
對驅動表進行全表掃描；
對返回的每一行利用連接欄位值實施索引惟一掃描；
利用從索引掃描中返回的ROWID值在從表中定位記錄；
合並主、從表中的匹配記錄。
因此，建立索引可避免多數排序操作。
2)用UNIION ALL替換UNION
UNION在進行表鏈接後會篩選掉重復的記錄，所以在表鏈接後會對所產生的結果集進行排序運算，刪除重復的記錄再返回結果。大部分應用中是不會產生重復記錄的，最常見的是過程表與歷史表UNION 。因此，採用UNION ALL操作符替代UNION，因為UNION ALL操作只是簡單的將兩個結果合並後就返回。
4.2 優化I/O
過多的I/O操作會佔用CPU時間、消耗大量內存和佔用過多的栓鎖，因此有必要對SQL的I/O進行優化。優化I/O的最有效方式就是用索引掃描代替全表掃描。
4.2.1 應用基於函數的索引
基於函數的索引(FUNCTION BASED INDEX，簡記為FBI)提供了索引計算列並在查詢中使用這些索引的能力。FBI的實質是對查詢所需中間結果進行預處理。如果一個FBI與查詢語句中的內嵌函數完全匹配，CBO在生成查詢計劃時，將自動啟用索引范圍掃描(INDEX RANGE SCAN)替換全表掃描(FULL TABLE SCAN)。考察下面的代碼段並用AUTOTRACE觀察創建FBI前後執行計劃的變化。
select * from emp where upper(ename)=』SCOTT』
創建FBI前，很明顯是全表掃描。
Execution Plan
……
1 0 TABLE ACCESS (FULL) OF 'EMPLOYEES' (Cost=2 Card=1 Bytes=22)
idle>CREATE INDEX EMP_UPPER_FIRST_NAME ON EMPLOYEES(UPPER(FIRST_NAME))；
索引已創建。
再次運行相同查詢，
Execution Plan
……
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPLOYEES' (Cost=1 Card=1 Bytes=22)
2 1 INDEX (RANGE SCAN) OF 'EMP_UPPER_FIRST_NAME' (NON-UNIQUE) (Cost=1 Card=1)
這一簡單的例子充分說明了FBI在SQL查詢優化中的作用。FBI所用的函數可以是用戶自己創建的函數，該函數越復雜，基於該函數創建FBI對SQL查詢性能的優化作用越明顯。
4.2.2 應用物化視圖和查詢重寫
物化視圖是一個預計算結果集，其中通常包含聚集與多表連接等復雜操作。資料庫自動維護物化視圖，且隨用戶的要求進行刷新。查詢重寫機制就是用資料庫中的替代對象(如物化視圖)將用戶提交的查詢重寫為完全不同但功能等價的查詢。查詢重寫對用戶透明，用戶完全按常規編寫訪問資料庫的查詢語句，優化程序(CBO)自動決定是否對用戶提交的查詢進行重寫。查詢重寫是提高查詢性能的一種非常有效的方法，尤其是在數據倉庫環境中針對匯總、多表連接以及其它高成本的操作方面。
下面以一個非常簡單的例子來演示物化視圖和查詢重寫在優化SQL查詢性能方面的作用。
select dept.deptno，dept.dname，count(*)
from emp，dept
where emp.deptno=dept.deptno
group by dept.deptno，dept.dname
查詢計劃及主要統計數據如下：
執行計劃：
-----------------------------------------
……
2 1 HASH JOIN (Cost=5 Card=14 Bytes=224)
3 2 TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=4 Bytes=52)
4 2 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=14 Bytes=42)
主要統計數據：
-----------------------------------------
305 recursive calls
46 consistent gets
創建物化視圖EMP_DEPT：
create materialized view emp_dept build immediate
refresh on demand
enable query rewrite
as
select dept.deptno，dept.dname，count(*)
from emp，dept
where emp.deptno=dept.deptno
group by dept.deptno，dept.dname
/
再次執行查詢，執行計劃及主要統計數據如下：
執行計劃：
-------------------------------------
……
1 0 TABLE ACCESS (FULL) OF 'EMP_DEPT' (Cost=2 Card=327 Bytes=11445)
主要統計數據：
------------------------------------
79 recursive calls
28 consistent gets
可見，在建立物化視圖之前，首先執行兩個表的全表掃描，然後進行HASH連接，再進行分組排序和選擇操作；而建立物化視圖後，CBO自動將上述復雜操作轉換為對物化視圖EMP_DEPT的全掃描，相關的統計數據也有了很大的改善，遞歸調用(RECURSIVE CALLS)由305降到79，邏輯I/O(CONSISTENT GETS)由46降為28。
4.2.3 將頻繁訪問的小表讀入CACHE
邏輯I/O總是快於物理I/O。如果資料庫中存在被應用程序頻繁訪問的小表，可將這些表強行讀入KEEP池，從而避免物理I/O的發生。
4.3 多表連接優化
最能體現查詢復雜性的就是多表連接，多表連接操作往往要耗費大量的CPU時間和內存，因此多表連接查詢性能優化往往是SQL優化的重點與難點。
4.3.1 消除外部連接
通過消除外部連接，不僅使得到的查詢更易於讀取，而且性能也經常可以得到改善。一般的思路是，有以下形式的查詢：
SELECT …，OUTER_JOINED_TABLE.COLUMN
FROM SOME_TABLE，OUTER_JOINED_TO_TABLE
WHERE …=OUTER_JOINED_TO_TABLE(+)
可轉換為如下形式的查詢：
SELECT …，(SELECT COLUMN FROM OUTER_ JOINED_TO_TABLE WHERE …)FROM SOME_TABLE；
4.3.2 謂詞前推，優化中間結果
多表連接的性能低下多數是因為連接操作與過濾操作的次序不合理，大多數用戶在編寫多表連接查詢時，總是先進行連接操作再應用過濾條件，這導致伺服器做了太多的無用功。針對這類問題，其優化思路就是盡可能將過濾謂詞前推，使不符合條件的記錄提前被篩選掉，只對符合條件的少數記錄進行連接處理，這樣可成倍的提高SQL查詢效能。
標准連接查詢如下：
Select a.prod_name，sum(b.sale_quant)，
sum(c.sale_quant)，sum(d.sale_quant)
From proct a，tele_sale b，online_sale c，store_sale d
Where a.prod_id=b.prod_id and a.prod_id=c.prod_id
and a.prod_id=d.prod_id And a.order_date>sysdate-90
Group by a.prod_id；
啟用內嵌視圖，且將條件a.order_date>sysdate-90前移，優化後代碼如下：
Select a.prod_name，b.tele_sale_sum，c.online_sale_sum，d.store_sale_sum From proct a，
(select sum(sal_quant) tele_sale_sum from proct，tele_sale
Where proct.order_date>sysdate-90 and proct.prod_id =tele_sale.prod_id) b，
(select sum(sal_quant) online_sale_sum
from proct，tele_sale
Where proct.order_date>sysdate-90 and proct.prod_id =online_sale.prod_id) c，
(select sum(sal_quant) store_sale_sum
from proct，store_sale
Where proct.order_date>sysdate-90 and proct.prod_id =store_sale.prod_id) d，
Where a.prod_id=b.prod_id and
a.prod_id=c.prod_id and a.prod_id=d.prod_id；
5 結束語
SQL語言在資料庫應用中佔有非常重要的地位，其性能的優劣直接影響著整個信息系統的可用性。論文從影響SQL性能的最主要的三個方面入手，分析了如何優化SQL查詢的I/O、避免高成本的排序操作和優化多表連接。需要強調的一點是，理解SQL語句所解決的問題比SQL調優本身更重要，因此SQL調優需要系統分析人員、開發人員和資料庫管理員密切協作。
參考文獻
[1]Thomas Kyte.Effective Oracle by Design：Design and Build High-performance Oracle Application[M]，The McGral- Hill Companies，Inc，2003
[2]Kevin Loney，George Koch，Oracle 9i：The Complete Reference[M]，The McGral-Hill Companies，Inc，2002
[3] Oracle9i SQL Reference release 2(9.2)[OL/M]，2002.10. http：//www.oracle.com/technology/
[4] Oracle9i Data Warehousing Guide release 2(9.2) [OL/M]，2002.03. http：//www.oracle.com/technology/
[5]Alexey Danchenkov，Donald Burleson，Oracle Tuning：The Definitive Reference[OL/M]，Rampant Techpress，2006.
[6] Oracle9i Database Concepts release 2(9.2) [OL/M]，2002.08. http：//www.oracle.com/technology/
[7] Oracle9i supplied plsql packages and types reference release 2(9.2) [OL/M]，2002.12. http：//www.oracle.com/ technology/
Ⅲ 請簡述項目中優化sql語句執行效率的方法,從哪些方面,sql語句性能如何分析
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
Ⅳ SQL語句的幾種優化方法
1、盡可能建立索引，包括條件列，連接列，外鍵列等。
2、盡可能讓where中的列順序與復合索引的列順序一致。
3、盡可能不要select *，而只列出自己需要的欄位列表。
4、盡可能減少子查詢的層數。
5、盡可能在子查詢中進行數據篩選 。
Ⅳ 查詢的SQL語句怎麼寫才能提高查詢效率
這是SQL語句優化的問題了。網上好多類似的文章，非常全面。
個人覺得比較常用的是：
SQL語句查詢中經常用到的欄位建索引，這樣可以非常明顯的提升查詢速度。
FROM表的順序，大表在前，小表在後，因為檢索的順序從後往前。
WHERE， WHERE A.COLUMN = B.COLUMN，把小表的欄位放在後邊（B表），大表在前。
固定值查詢的放在後邊 COLUMN = '1'這種。因為這個也是從後往前的順序。
如果有(NOT) IN (SELECT ...) 盡量避免，因為IN裡面也是一個大的查詢，使用 (NOT) EXISTS的語法代替。
還有UNION和UNION ALL，多表聯合，UNION的作用是可以去掉重復，如果多表沒有重復數據，使用UNION ALL效率也會大大提高。