sql 優化整理

2021-08-28 03:15:07 字數 1802 閱讀 6794

1.避免無計畫的全表掃瞄

如下情況進行全表掃瞄:

-該錶無索引

-對返回的行無任何限制條件(無where子句)

-對索引主列(索引的第一列)無限制條件

-對索引主列的條件含在表示式中

-對索引主列的限制條件是is(not)null或!=

-對索引主列的限制條件是like操作 且 值是乙個bind variable或%打頭的值

2.只使用選擇性索引

索引的選擇性是指索引列中不同值的數目和標誌中記錄數的比,選擇性最好的是非空列的唯一索引為1.0。

復合索引中列的次序的問題:

1 在限定條件裡最頻繁使最清晰的列)應該是主列

如果1和2 不一致,可用的列應該是主列

2 最具有選擇性的列(即以考慮建立多個索引。

在復合索引和多個單個索引中做選擇:

考慮選擇性 考慮讀取索引的次數 考慮and-equal操作

3.管理多表連線(nexted loops,merge joins 和hash joins)優化聯接操作

merge joins是集合操作 nested loops 和hash joins 是記錄操作返回第一批記錄迅速

merge joins的操作適用於批處理操作,巨大表和遠端查詢

1全表掃瞄–>2排序–>3比較和合併 效能開銷主要在前兩步

適用全表掃瞄的情形,都適用merge joins操作(比nested loops有效)

改善1的效率:優化i/o,提高使用oracle多塊讀的能力,使用並行查詢的選項

改善1的效率:提高sort_area_size的值,使用sort direct writes,為臨時段提供專用表空間

4.管理包含檢視的sql語句

優化器執行包含檢視的sql語句有兩種方法:

-先執行檢視,完成全部的結果集,然後用其餘的查詢條件做過濾器執行查詢

-將視**本整合到查詢裡去

含有group by子句的檢視不能被整合到乙個大的查詢中去。

在檢視中使用union,不阻止檢視的sql整合到查詢語法中去。

5.優化子查詢

6.使用復合keys/star 查詢

7.恰當地索引connect by 操作

8.限制對遠端表的訪問

9.管理非常巨大的表的訪問

-管理資料接近(proximity)記錄在表中的存放按對錶的範圍掃瞄中最長使用的列排序,按次序儲存資料有助於範圍掃瞄,尤其是對大表。

-避免沒有幫助的索引掃瞄 當返回的資料集合較大時,使用索引對sga的資料塊快取占用較大,影響其他使用者;全表掃瞄還能從oracle的多塊讀取機制和「一致性獲取/每塊」特性中受益。

-建立充分索引的表 使訪問索引能夠讀取較全面的資料,建立僅主列不同的多個索引

-建立hash簇

-建立分割表和檢視

-使用並行選項

10. 使用union all而不是union

union all 操作不包括sort unique 操作,第一行索引的響應速度快,多數情況下不用臨時段完成操作

union all 建立的檢視用在查詢裡可以整合到查詢的語法中去,提供效率

11.避免在sql裡使用pl/sql功能呼叫

12.繫結變數(bind variable)的使用管理

使用bind bariable 和execute using 方式

將like:name||』%』改寫成between:name and :name||char(225),已避免進行全表掃瞄,而是使用索引。

13.回訪優化程序

資料變化後,重新考察優化情況

sql優化提速整理

sql優化提速整理 場景描述 在我們實際開發中,隨著業務的不斷增加,資料量也在不斷的攀公升,這樣就離不開乙個問題 資料查詢效率優化 根據自己的以往實際專案工作經驗和學習所知,現在對sql查詢優化做乙個簡單的梳理總結,總結的不好之處,望多多指點交流學習 主要通過以下幾個點來進行總結分析 索引 語句本身...

sql優化技術整理

1.禁止使用select 需要哪些字段查哪些字段 2.使用select in 的時候,如果存在子查詢,使用exist 代替in select from class a where id in select id from class b 應使用 select from class a a where...

SQL優化的一些策略(整理篇)

當我們資料量大的時候,我們的sql執行效率往往不是那麼可觀,雖然結果也執行的出來 sql也是正確的,但是有的時候我們不得不更改原來的sql以提公升效能。就像排序演算法一樣,邏輯簡單的冒泡也能實現功能,但是資料量大的時候執行效率就非常 的差,而我們的快速排序可以出色的解決我們的需求。對於 innodb...