華閱文章網
sql語句性能如何優化
查詢速度慢的原因很多，常見如下幾種：
1、沒有索引或者沒有用到索引（這是查詢慢最常見的問題，是程序設計的缺陷）
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網絡速度慢
6、查詢出的數據量過大（可以采用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖（這也是查詢慢最常見的問題，是程序設計的缺陷）
8、sp_lock,sp_who，活動的用戶查看，原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
怎樣優化SQL語句提高效率
我們要做到不但會寫SQL，還要做到寫出性能優良的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）。 以上是我對于這個問題的解答，希望能夠幫到大家。
怎樣優化SQL語句的執行
環境：oracle 817 + linux + 陣列柜 swd_billdetail 表5000萬條數據 SUPER_USER 表2800條數據 連接列上都有索引，而且super_user中的一條對應于swd_billdetail表中的很多條記錄表與索引都做了分析。
實際應用的查詢為： select a。CHANNEL, B。
user_class from swd_billdetail B, SUPER_USER A where A。cn = B。
cn； 這樣在分析時導致查詢出的數據過多，不方便，所以用count(a。 CHANNEL||B。
user_class)來代替，而且count(a。CHANNEL||B。
user_class)操作本身并不占用過多的時間，所以可以接受此種替代。 利用索引查詢出SWD_BILLDETAIL表中所有記錄的方法 SQL> select count(id) from SWD_BILLDETAIL; COUNT(ID) ---------- 53923574 Elapsed: 00:02:166。
00 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=18051 Card=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'SYS_C001851' (UNIQUE) (Cost=18051 Card=54863946) Statistics ---------------------------------------------------------- 0 recursive calls 1952 db block gets 158776 consistent gets 158779 physical reads 1004 redo size 295 bytes sent via SQL*Net to client 421 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed 利用全表掃描從SWD_BILLDETAIL表中取出全部數據的方法。 SQL> select count(user_class) from swd_billdetail; COUNT(USER_CLASS) ----------------- 53923574 Elapsed: 00:11:703。
07 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=165412 Card=1 Bytes=2) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'SWD_BILLDETAIL' (Cost=165412 Card=54863946 Bytes=109727892) Statistics ---------------------------------------------------------- 0 recursive calls 8823 db block gets 1431070 consistent gets 1419520 physical reads 0 redo size 303 bytes sent via SQL*Net to client 421 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed select count(a。 CHANNEL||B。
user_class) from swd_billdetail B, SUPER_USER A where A。cn = B。
cn; EXEC_ORDER PLANLINE ---------- ----------------------------------------------------------------------------------------------------------- 6 SELECT STATEMENT OPT_MODE:CHOOSE (COST=108968,CARD=1,BYTES=21) 5 SORT (AGGREGATE) (COST=,CARD=1,BYTES=21) 4 NESTED LOOPS (COST=108968,CARD=1213745,BYTES=25488645) 1 TABLE ACCESS (FULL) OF 'SWORD。 SUPER_USER' (COST=2,CARD=2794,BYTES=27940) 3 TABLE ACCESS (BY INDEX ROWID) OF 'SWORD。
SWD_BILLDETAIL' (COST=39,CARD=54863946,BYTES=603503406) 2 INDEX (RANGE SCAN) OF 'SWORD。 IDX_DETAIL_CN' (NON-UNIQUE) (COST=3,CARD=54863946,BYTES=) 這個查詢耗費的時間很長，需要1個多小時。
運行后的信息如下： COUNT(A。CHANNEL||B。
USER_CLASS) ------------------------------ 1186387 Elapsed: 01:107:6429。 87 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=108968 Card=1 Bytes=21) 1 0 SORT (AGGREGATE) 2 1 NESTED LOOPS (Cost=108968 Card=1213745 Bytes=25488645) 3 2 TABLE ACCESS (FULL) OF 'SUPER_USER' (Cost=2 Card=2794Bytes=27940) 4 2 TABLE ACCESS (BY INDEX ROWID) OF 'SWD_BILLDETAIL' (Cost=39 Card=54863946 Bytes=603503406) 5 4 INDEX (RANGE SCAN) OF 'IDX_DETAIL_CN' (NON-UNIQUE) (Cost=3 Card=54863946) Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 1196954 consistent gets 1165726 physical reads 0 redo size 316 bytes sent via SQL*Net to client 421 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 1 rows processed 將語句中加入hints，讓oracle的優化器使用嵌套循環，并且大表作為驅動表，生成新的執行計劃： select /*+ ORDERED USE_NL(A) */ count(a。
CHANNEL||B。user_class) from swd_billdetail B, SUPER_USER A where A。
cn = B。cn; EXEC_ORDER PLANLINE ---------- ----------------------------------------------------------------------------------------------------- 6 SELECT STATEMENT OPT_MODE:CHOOSE (COST=109893304,CARD=1,BYTES=21) 5 SORT (AGGREGATE) (COST=,CARD=1,BYTES=21) 4 NESTED LOOPS (COST=109893304,CARD=1213745,BYTES=25488645) 1 TABLE ACCESS (FULL) OF 'SWORD。
SWD_BILLDETAIL' (COST=165412,CARD=54863946,BYTES=603503406) 3 TABLE ACCESS (BY INDEX ROWID) OF 'SWORD。SUPER_USER。
sql語句的優化
由于SQL優化起來比較復雜，并且還會受環境限制，在開發過程中，寫SQL必須必須要遵循以下幾點的原則： *采用自下而上的順序解析WHERE子句，根據這個原理，表之間的連接必須寫在其他WHERE條件之前， 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾. 例如： （低效） SELECT … FROM EMP E WHERE SAL > 50000 AND JOB = 'MANAGER' AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=*）； （高效） SELECT … FROM EMP E WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=*) AND SAL > 50000 AND JOB = 'MANAGER'; *子句中避免使用'*' 當在SELECT子句中列出所有的COLUMN時，使用動態SQL列引用 ‘*’ 是一個方便的方法.可是，這是一個非常低效的方法. 實際上，ORACLE在解析的過程中， 會將'*' 依次轉換成所有的列名， 這個工作是通過查詢數據字典完成的， 這意味著將耗費更多的時間. 3.使用表的別名（Alias） 當在SQL語句中連接多個表時， 請使用表的別名并把別名前綴于每個Column上.這樣一來，就可以減少解析的時間并減少那些由Column歧義引起的語法錯誤. 注：Column歧義指的是由于SQL中不同的表具有相同的Column名，當SQL語句中出現這個Column時，SQL解析器無法判斷這個Column的歸屬。
SQL語句優化的目的是什么呢
優化的目的 對應用程序的優化通常可分為兩個方面：源代碼優化和SQL語句優化。
由于涉及到對程序邏輯的改變，源代碼的優化在時間成本和風險上代價很高（尤其是對正在使用中的系統進行優化） 。另一方面，源代碼的優化對數據庫系統性能的提升收效有限，因為應用程序對數據庫的操作最終要表現為SQL語句對數據庫的操作。
對SQL語句優化有以下一些直接原因： *語句是對數據庫（數據） 進行操作的惟一途徑，應用程序的執行最終要歸結為SQL語句的執行，SQL語句的效率對數據庫系統的性能起到了決定性的作用。 *語句消耗了70%~90%的數據庫資源。
*語句獨立于程序設計邏輯，對SQL語句進行優化不會影響程序邏輯，相對于對程序源代碼的優化，對SQL語句優化在時間成本和風險上的代價都很低。 *語句可以有不同的寫法，不同的寫法在性能上的差異可能很大。
*語句易學，難精通。SQL語句的性能往往同實際運行系統的數據庫結構、記錄數量等有關，不存在普遍適用的規律來提升性能。
優化數據庫的思想及sql語句優化有哪些原則
優化數據庫的思想： ================ 1、關鍵字段建立索引。
2、使用存儲過程，它使SQL變得更加靈活和高效。 3、備份數據庫和清除垃圾數據。
4、SQL語句語法的優化。（可以用Sybase的SQL Expert，可惜我沒找到unexpired的序列號） 5、清理刪除日志。
SQL語句優化的原則： ================== 1、使用索引來更快地遍歷表。 缺省情況下建立的索引是非群集索引，但有時它并不是最佳的。
在非群集索引下，數據在物理上隨機存放在數據頁上。合理的索引設計要建立在對各種查詢的分析和預測上。
一般來說： ①.有大量重復值、且經常有范圍查詢 （between, > , =,。
SQL語句優化的原則是什么呢
優化數據庫的思想 1、關鍵字段建立索引。
2、使用存儲過程，它使SQL變得更加靈活和高效。 3、備份數據庫和清除垃圾數據。
4、SQL語句語法的優化。 5、清理刪除日志。
三、SQL語句優化的原則 不要以為只有SELECT語句是查詢。實際上，帶有任何WHERE條件的DML(INSERT、UPDATE、DELETE)語句中都包含查詢要求，在后面的文章中，當說到查詢時，不一定只是指SELECT語句，也有可能指DML語句中的查詢部分。
我們知道，SQL語句同其它語言（如C語言）的語句不一樣，它是非過程化（non-procedural）的語句，即當你要取數據時，不需要告訴數據庫通 過何種途徑去取數據，如到底是通過索引取數據，還是應該將表中的每行數據都取出來，然后再通過一一比較的方式取數據（即全表掃描）。 為了實現一個查詢，內核必須為每個查詢定制一個查詢策略，或為取出符合條件的數據生成一個執行計劃（execution plan）。
典型的，對于同一個查詢，可能有幾個執行計劃都符合要求，都能得到符合條件的數據。例如，參與連接的表可以有多種不同的連接方法，這取決于連接條件和優化器采用的連接方法。
為了在多個執行計劃中選擇最優的執行計劃，優化器必須使用一些實際的指標來衡量每個執行計劃使用的資源（I/0次數、 CPU等），這些資源也就是我們所說的代價（cost）。如果一個執行計劃使用的資源多，我們就說使用執行計劃的代價大。
以執行計劃的代價大小作為衡量標準，優化器選擇代價最小的執行計劃作為真正執行該查詢的執行計劃，并拋棄其它的執行計劃。
oracle中如何優化sql語句的,用什么方法
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表的交集. SELECT * FROM LOCATION L , CATEGORY C, EMP E WHERE *_NO BETWEEN 1000 AND 2000 AND *_NO = *_NO AND * = * 將比下列SQL更有效率 SELECT * FROM EMP E , LOCATION L , CATEGORY C WHERE *_NO = *_NO AND * = * AND *_NO BETWEEN 1000 AND 2000 3. WHERE子句中的連接順序. ORACLE采用自下而上的順序解析WHERE子句，根據這個原理，表之間的連接必須寫在其他WHERE條件之前， 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾. 例如： （低效，執行時間156.3秒） SELECT … FROM EMP E WHERE SAL > 50000 AND JOB = 'MANAGER' AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=*）； （高效，執行時間10.6秒） SELECT … FROM EMP E WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=*) AND SAL > 50000 AND JOB = 'MANAGER'; 4. SELECT子句中避免使用 ‘ * ‘ 當你想在SELECT子句中列出所有的COLUMN時，使用動態SQL列引用 ‘*’ 是一個方便的方法.不幸的是，這是一個非常低效的方法. 實際上，ORACLE在解析的過程中， 會將'*' 依次轉換成所有的列名， 這個工作是通過查詢數據字典完成的， 這意味著將耗費更多的時間. 5. 減少訪問數據庫的次數 當執行每條SQL語句時， ORACLE在內部執行了許多工作： 解析SQL語句， 估算索引的利用率， 綁定變量 ， 讀數據塊等等. 由此可見， 減少訪問數據庫的次數 ， 就能實際上減少ORACLE的工作量. 例如， 以下有三種方法可以檢索出雇員號等于0342或0291的職員. 方法1 （最低效） SELECT EMP_NAME , SALARY , GRADE FROM EMP WHERE EMP_NO = 342; SELECT EMP_NAME , SALARY , GRADE FROM EMP WHERE EMP_NO = 291； 方法2 （次低效） DECLARE CURSOR C1 (E_NO NUMBER) IS SELECT EMP_NAME,SALARY,GRADE FROM EMP WHERE EMP_NO = E_NO; BEGIN OPEN C1(342); FETCH C1 INTO …，..，.. ； OPEN C1(291); FETCH C1 INTO …，..，.. ； CLOSE C1; END； 方法3 （高效） SELECT *_NAME , * , *, *_NAME , * , * FROM EMP A,EMP B WHERE *_NO = 342 AND *_NO = 291； 注意： 在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數， 可以增加每次數據庫訪問的檢索數據量 ，建議值為200. 6. 使用DECODE函數來減少處理時間 使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表. 例如： SELECT COUNT(*),SUM(SAL) FROM EMP WHERE DEPT_NO = 0020 AND ENAME LIKE 'SMITH%'; SELECT COUNT(*),SUM(SAL) FROM EMP WHERE DEPT_NO = 0030 AND ENAME LIKE 'SMITH%'； 你可以用DECODE函數高效地得到相同結果 SELECT COUNT(DECODE(DEPT_NO,0020,'X',NULL)) D0020_COUNT, COUNT(DECODE(DEPT_NO,0030,'X',NULL)) D0030_COUNT, SUM(DECODE(DEPT_NO,0020,SAL,NULL)) D0020_SAL, SUM(DECODE(DEPT_NO,0030,SAL,NULL)) D0030_SAL FROM EMP WHERE ENAME LIKE 'SMITH%'； 類似的，DECODE函數也可以運用于GROUP BY 和ORDER BY子句中. 7. 用TRUNCATE替代DELETE 當刪除表中的記錄時，在通常情況下， 回滾段（rollback segments ） 用來存放可以被恢復的信息. 如果你沒有COMMIT事務，ORACLE會將數據恢復到刪除之前的狀態（準確地說是恢復到執行刪除命令之前的狀況） 而當運用TRUNCATE時， 回滾段不再存放任何可被恢復的信息.當命令運行后，數據不能被恢復.因此很少的資源被調用，執行時間也會很短. TRUNCATE只在刪除全表或分區適用，TRUNCATE是DDL不是DML8. 用Where子。
