Oracle SQL的優化(1)
2024-08-29 13:41:55
供稿：網友
1、在Oracle中有兩種操作可以直接訪問Table
(1)Table access Full
--為了優化全表掃描的性能，Oracle在每次數據庫讀取中都會讀取多個數據塊；
--只要查詢中沒有where子句，Oracle就會采用全表掃描。
(2)Table Access by RowID(基于RowID的訪問)
--RowID記錄了數據行的物理存儲位置；
--Oracle使用索引將數據值與RowID相關聯，從而與數據物理位置相關聯。
2、提示：在select要害字之后使用/*+... */3、使用Index:
(1)Index unique scan
select * from bookshelf where title='WTL'
假設在title列上有唯一索引，則這個語句的執行方式為：
a)首先通過insex unique scan操作訪問title列索引；
b)從索引返回與title值'WTL'相匹配的RowID值，然后利用此RowID值
通過Table Access by RowID操作來查詢BookShelf表。
(2)Index range scan
假如基于一個值的范圍查詢或者利用一個非唯一索引進行查詢，則可以使用index range
scan操作對索引進行查詢。由于index range scan操作需要從索引中讀取多個值，所以它的
效率要比index unique scan低。
假設emp表的ename上有一個非唯一索引idx_emp_ename，假如在查詢的where子句中給出
ename的限定條件，則可能會執行idx_emp_ename索引的index range scan操作，應為ename上
的這和索引是一個非唯一性索引，所以數據庫不能在該索引上執行index unique scan操作，
即便是ename等于查詢中的單個值也不行，即...where ename='GLEDESON' 和
...where ename like 'G%'都是執行index range scan 操作的。
注重：假如在like條件中的開頭使用了通配符則查詢將不會使用索引(如:like '%M%')
來解決這個查詢。
4、使用索引的注重事項:
(1)假如設置了一個索引列等(=)一某個值,則將使用index range scan操作
--唯一索引(unique index)
*索引--
--非唯一索引(non-unique index) (2)要使用一個索引不一定要給出明確的值,index range scan操作可為值的范圍掃描一個索引，具
體的操作符有"<"、">"、"like",注重：不要在like算式的開頭使用通配符！！
--索引的全表掃描
*全表掃描--
--表的全表掃描
(3)假如在where條件中使用了函數，則不會使用索引，除非索引是基于函數的！
(4)在查詢條件中使用了is null、is not null則不會使用索引。
(null值是不存在索引中的)
*在大多數情況下，執行全表掃描將會比執行用索引返回的所有值執行索引掃描更為有效！
(5)假如在查詢條件中使用了"!="操作將不會使用索引，"<>"也不會。
(6)使用not in、in操作符也不會使用索引，在Oracle中，幾乎所有的not in、in操作都可以
用not exists、exists來代替。...where exists(select 'x' from ...where ...)
*使用exists子句，不管從子查詢中抽取什么數據，它只會查看where子句。這樣優化器就
不會遍歷整個表而僅根據索引就可以完成工作(這里假設where子句中的列上使用了index).
通過使用exists，Oracle系統會首先檢查主查詢，然后運行子查詢直到它找到第一個匹
配項，這樣就節省了時間。Oracle在執行in查詢時，首先執行子查詢，并將獲得的結果列
表存放到一個加了索引的臨時表中，在執行子查詢之前，先將主查詢掛起，待子查詢執行
完畢存放到臨時表中以后再執行主查詢，這就是使用exists比使用in通常查詢速度快的原
因。
(7)假如設置了復合索引的首列等于某個值，則使用該索引。
*在復合索引中，Oracle9i之前，只有在限定條件中使用了復合索引的首列，才會使用該索
引，但Oracle9i之后，索引的跳躍掃描特性答應優化器潛在地使用連接索引，即使復合索
引的首列沒有出現在where子句中也是如此！
(8)假如選擇了一個索引列的max或min函數，則優化器會使用此索引來快速地找到列的最大最小
值。
(9)索引的選擇性：假設一個表中有100行，其中的一列(這列上有索引)中不重復的紀錄有80個，
也就是說有20行紀錄有重復，則這個索引的選擇性為80/100=0.80，即這列上的索引的選擇
性是80%，選擇性越高，列中每個不同的值返回的行的數目就越少。
假如使用的優化模式是CBO，并且索引是經過分析的，則優化程序就會考慮索引的選擇
性來判定使用索引是否會降低執行查詢的成本。
