1、現狀描述
sql執行時間長、資料查詢慢
2、問題物件
sql執行語句(特別是多表多條件關聯查詢資料)
3、理論知識
1、oracle優化器
oracle優化器：oracle資料庫中的優化器又叫查詢優化器(queryoptimizer)。它是sql分析和執行的優化工具，它負責生成、制定sql的執行計畫。
oracle優化器優化方式
基於規則的優化方式(rule-basedoptimization,簡稱為rbo)
它根據指定的規則順序，對指定的表進行執行計畫的選擇。它著一套嚴格的使用規則，只要你按照它去寫sql語句，無論資料表中的
內容怎樣，也不會影響到你的「執行計畫」，也就是說rb對資料不「敏感」。要求開發人員了解rbo的各項細則。在oracle
10g中完全被cbo取代。
基於代價的優化方式(cost-based optimization,簡稱為cbo)。
cbo是一種比rbo更加合理、可靠的優化器，它是從oracle 8中開始引入，在oracle10g中完全取代rbo。cbo是計算各種可能「執行
計畫」的「代價」，即cost，從中選用cost最低的執行方案，作為實際執行方案。它依賴資料庫物件的統計資訊，統計資訊的準確與否會影響c
bo做出最優的選擇。如果對一次執行sql時發現涉及物件(表、索引等)沒有被分析、統計過，那麼oracle會採用一種叫做動態取樣的技術，
動態的收集表和索引上的一些資料資訊。
2、oracle索引
oracle索引是一種供伺服器在表中快速查詢乙個行的資料庫結構。合理使用索引能夠大大提高資料庫的執行效率。
在oracle中，索引是一種供伺服器在表中快速查詢乙個行的資料庫結構。在資料庫中建立索引主要有以下作用。
(1)快速訪問資料。
(2)既可以改善資料庫效能，又可以保證列值的唯一性。
(3)實現表與表之間的參照完整性
(4)在使用order by、group by子句進行資料檢索時，利用索引可以減少排序和分組的時間。
3、優化方向
a、去掉不必要的大型表的全表掃瞄
b、去掉不必要的大型表的全表掃瞄
c、快取小型表的全表掃瞄
d、檢驗優化索引的使用
e、檢驗優化的連線技術
f、盡可能減少執行計畫的cost
4、具體優化方法
1、查詢條件(where後面的子句)優化
避免全表掃瞄，應考慮在where及order by等列上建立索引，否則將導致進行全表掃瞄。。
避免在where子句中對字段進行null值判斷，否則將導致放棄使用索引而進行全表掃瞄。
避免在where子句中使用!=或<>操作符，否則將導致放棄使用索引而進行全表掃瞄。
避免用or連線條件，如果有部分字段存在索引，部分不存在索引，則將導致放棄使用索引而進行全表掃瞄，建議使用union all代替。
慎用in 和 not in 也要慎用，否則會導致全表掃瞄。
使用exists替換in問題
子查詢結果集小，用in
外表小，子查詢表大，用exists
建議實際選取哪個可以對比兩個sql的執行計畫
應盡量避免在 where 子句中對字段進行表示式操作，這將導致引擎放棄使用索引而進行全表掃瞄。如：
select id from t where num / 2 = 100
優化為：
select id from t where num = 100 * 2
應盡量避免在where子句中對字段進行函式函式、算術運算或其他表示式運算操作，否則將導致放棄使用索引而進行全表掃瞄。如：
-- name以abc開頭的id
select id from t where substring(name, 1, 3) = 』abc』
--2005-11-30』生成的id
select id from t where datediff(day, createdate, 』2005 - 11 - 30′) = 0
應改為:
select id from t where name like 'abc%'
select id from t where createdate >= '2005-11-30' and createdate < '2005-12-1'
2、對結果進行優化
update 語句，如果只更改1、2個字段，不要update全部字段，否則頻繁呼叫會引起明顯的效能消耗，同時帶來大量日誌。
對於多張大資料量(這裡幾百條就算大了)的表join，要先分頁再join，否則邏輯讀會很高，效能很差。
select count(*) from table;這樣不帶任何條件的count會引起全表掃瞄，並且沒有任何業務意義，是一定要杜絕的。
盡量避免向客戶端返回大資料量，若資料量過大，應該考慮是否使用分頁
3、其他優化
索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或
update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。乙個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到
的列上建的索引是否有必要。
應盡可能的避免更新聚集索引(clustered)資料列，因為聚集索引資料列的順序就是表記錄的物理儲存順序，一旦該列值改變將導致整個表記錄的
順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新集索引資料列，那麼需要考慮是否應將該索引建為聚集索引
盡量使用數字型字段，若只含數值資訊的字段盡量不要設計為字元型，這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢
和連線時會逐個比較字串中每乙個字元，而對於數字型而言只需要比較一次就夠了。
盡量使用表變數來代替臨時表。如果表變數包含大量資料，請注意索引非常有限(只有主鍵索引)。
避免頻繁建立和刪除臨時表，以減少系統表資源的消耗。臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重複引用
大型表或常用表中的某個資料集時。但是，對於一次性事件， 最好使用匯出表。
在新建臨時表時，如果一次性插入資料量很大，那麼可以使用 select into 代替 create table，避免造成大量
log，以提高速度;如果資料量不大，為了緩和系統表的資源，應先create table，然後insert。
如果使用到了臨時表，在儲存過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table
，這樣可以避免系統表的較長時間鎖定。
盡量避免使用游標，因為游標的效率較差，如果游標操作的資料超過1萬行，那麼就應該考慮改寫。
使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
與臨時表一樣，游標並不是不可使用。對小型資料集使用 fast_forward 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所
需的資料時。在結果集中包括「合計」的例程通常要比使用游標執行的速度快。如果開發時
間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
在所有的儲存過程和觸發器的開始處設定 set nocount on ，在結束時設定 set nocount off
。無需在執行儲存過程和觸發器的每個語句後向客戶端傳送 done_in_proc 訊息。
盡量避免大事務操作，提高系統併發能力。
oracle優化技巧
我覺得主要應該從5個方面進行調整 1.去掉不必要的大型表的全表掃瞄 2.快取小型表的全表掃瞄 3.檢驗優化索引的使用 4.檢驗優化的連線技術 5.盡可能減少執行計畫的cost 現在簡單的舉幾個例子 where子句中有 將不使用索引 select account name from test wher...
oracle 技巧 sql 優化
it168 技術文件 一 問題的提出 在應用系統開發初期，由於開發資料庫資料比較少，對於查詢sql語句，複雜檢視的的編寫等體會不出sql語句各種寫法的效能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中資料的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中乙個很重要的方面...
Oracle效能優化技巧
今天沒事來說說oracle效能優化的技巧。1.選用適合的oracle優化器 oracle的優化器共有3種 1.rule 基於規則 2.cost 基於成本 3.choose 選擇性 設定預設的優化器，可以通過對init.ora檔案中optimizer mode引數的各種宣告，如rule，cost，ch...