最近在做有關查詢資料庫的工作，由於乙個表的資料量過大，導致程式程序卡死情況出現，sql優化迫在眉睫，索引閃亮登場！
oracle中查詢走索引的情況：
1、對返回的行無任何限定條件，即沒有where子句。
2、未對資料表與任何索引主列相對應的行限定條件。
例如：在id-name-time列建立了三列復合索引，那麼僅對name列限定條件不能使用這個索引，因為name不是索引的主列。
3、對索引的主列有限定條件，但是在條件表示式裡使用以下表示式則會使索引失效，造成權標掃瞄：
（1）where子句中對字段進行函式、表示式操作，這將導致引擎放棄使用索引而進行全表掃瞄。
（2）查詢欄位is null時索引失效，引起全表查詢。
解決辦法：sql語法中使用null會有很多麻煩，最好索引列時not null的；對於is null，可以建立組合索引， nvl(字段,0),對錶和索引analyse後，is null查詢時可以重新啟用索引查詢,但是效率還不是值得肯定；is not null時永遠不會使用索引。一般資料量大的表不要用is null查詢。
（3） 查詢條件中使用了不等於操作符（<>、!=）會限制索引、引起全表掃瞄 。
解決方法：通過把不等於操作符改成or，可以使用索引，避免全表掃瞄。
例如，把column<>10，改成column<10 or column>10，就可以使用索引了。
（4）對索引的主列有限定條件，但是條件使用like操作以及值以『%』開始或者值是乙個賦值變數。
例如：where city like '%大連%'。
select * from citys where name like '%大連' (不使用索引)
select * from citys where name like '大連%' (使用索引) 。
解決辦法：首先盡量避免模糊查詢，如果必須使用，不採用全模糊查詢，也應盡量採用右模糊查詢， 即like 『…%』，是會使用索引的；左模糊like 『%...』無法直接使用索引，但可以利用reverse + function index 的形式，變化成 like 『…%』；
全模糊查詢是無法優化的，一定要使用的話建議使用搜尋引擎。
4、 or語句使用不當會引起全表掃瞄
原因：where子句中比較的兩個條件，乙個有索引，乙個沒索引，使用or則會引起全表掃瞄。
例如：where a=：1 or b=：2，a上有索引，b上沒索引，則比較b=：2時會重新開始全表掃瞄
5、組合索引
排序時應按照組合索引中各列的順序進行排序，即使索引中只有乙個列是要排序的，否則排序效能會比較差。
例如：
create index skip1 on emp5(job,empno，date);
select job，empno from emp5 where job=』manager』 and empno=』10』 order by job,empno,date desc;
6、 update語句，如果只更改1、2個字段，不要update全部字段，否則頻繁呼叫會引起明顯的效能消耗，同時帶來大量日誌。
7、 對於多張大資料量的表join，要先分頁再join，否則邏輯讀會很高，效能很差。
8、 select count(*) from table；
這樣不帶任何條件的count會引起全表掃瞄，並且沒有任何業務意義，是一定要杜絕的。
9、 sql的where條件要繫結變數，比如where column= 1，不要寫成where column=『aaa』，這樣會導致每次執行時都會重新分析，浪費cpu和記憶體資源。
10、 不要使用in操作符，這樣資料庫會進行全表掃瞄。
11、 not in 使用not in也不會走索引
12、 > 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查詢。
但有的情況下可以對它進行優化，如乙個表有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的記錄索引。
13、 union操作符
union在進行表鏈結後會篩選掉重複的記錄，所以在表鏈結後會對所產生的結果集進行排序運算，刪除重複的記錄再返回結果。
實際大部分應用中是不會產生重複的記錄，最常見的是過程表與歷史表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
這個sql在執行時先取出兩個表的結果，再用排序空間進行排序刪除重複的記錄，最後返回結果集，如果表資料量大的話可能會導致用磁碟進行排序。
推薦方案：採用union all操作符替代union，因為union all操作只是簡單的將兩個結果合併後就返回。
14、 where後面的條件順序影響
select * from zl_yhjbqk where dy_dj = '1k以下' and xh_bz=1
select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1k以下'
以上兩個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佔用率明顯比第一條低。
15、查詢表順序的影響
在from後面的表中的列表順序會對sql執行效能影響，在沒有索引及oracle沒有對錶進行統計分析的情況下oracle會按表出現的順序進行鏈結，
由此因為表的順序不對會產生十分耗伺服器資源的資料交叉。（注：如果對錶進行了統計分析，oracle會自動先進小表的鏈結，再進行大表的鏈結）
表連線時，資料量大的為主表效率更高。
16、oracle的解析器按照從右到左的順序處理from子句中的表名，因此from子句中寫在最後的表（基礎班 driving table）將先被最先處理。
在from子句中包含多個表的情況下，必須選擇記錄條數最少的表作為基礎表，放在最後。
以下幾種情況快速判斷基礎表（驅動表）：
（1）where子句中盡量使用索引。
（2）連線操作應返回較少行上驅動。
（3）如果where中包含選擇性條件，如where id=1，應將最具有選擇性部分放在表示式最後。
（4）如果只有乙個表有索引，另一表無索引，無索引的表通常作為基礎表。
oracle 資料庫訪問效能優化 2
oracle資料庫效能優化 降低io 影響到oracle效能的因素主要可以從硬體和軟體兩個方面劃分，本文通過對oracle資料庫架構的分析，提出從硬體方面oltp系統優化oracle資料庫效能的方法，不足之處歡迎拍磚。oracle資料庫物理儲存架構 oracle資料庫物理檔案增長情況 oracle ...
優化Oracle資料庫效能
優化策略 為了保證oracle資料庫執行在最佳的效能狀態下，在資訊系統開發之前就應該考慮資料庫的優化策略。優化策略一般包括伺服器作業系統引數調整 資料庫引數調整 網路效能調整 應用程式sql語句分析及設計等幾個方面，其中應用程式的分析與設計是在資訊系統開發 分析評價oracle資料庫效能主要有資料庫...
Oracle資料庫效能優化
url size medium 為了保證oracle資料庫執行在最佳的效能狀態下，在資訊系統開發之前就應該考慮資料庫的優化策略。優化策略一般包括伺服器作業系統引數調整 資料庫引數調整 網路效能調整 應用程式sql語句分析及設計等幾個方面，其中應用程式的分析與設計是在資訊系統開發。分析評價oracle...