sql tuning

sembh發表於2010-07-19

sql調優(資料庫效能80%問題):
1 減少響應時間
2 減少資源的使用

找出有問題的sql
自動:addm,頂端sql
手動:v$檢視,statspack
執行改變:
sql語句的結構
索引訪問結構

驅動表有最好的過濾器
少量行數返回到下一個步驟
檢視被有效的利用
每個表是被高效地訪問
檢查sql語句中的屬性和表中的行數
全表掃描並不意味著效率低下。


避免在where 字句中轉化column
避免mixed-mode的表達以及提防隱式型別轉換
為特殊任務編寫單獨的sql語句和適當的使用sql建構。
使用exists或in為子查詢的要求。
根據提示謹慎改變訪問路徑和連線順序。

移除不必要的索引,以加快DML
索引的關鍵效能訪問通道
在現有的索引中重新排列columns
新增columns到索引中,以改善選擇性
基於使用型別建立適當的索引:
考慮索引組織表

簡單的設計
資料建模
表和索引(表結構設計是最好的最佳化方法,最重要的最佳化是設計)
使用檢視
寫有效的sql
遊標共享
使用棒定變數
sql與pl/sql對應
動態sql

資料地點查詢最佳化統計表
統計表:儲存在資料字典表,資料的陳述必須真實
收集使用:dbms_stats包,動態取樣。

可以使用以下的初始化引數控制最佳化行為(使用其預設設定):
cursor_sharing
db_file_multiblock_read_count
optimizer_index_caching
optimizer_index_cost_adj
optimizer_mode
pga_aggregate_target

所考慮的最佳化因數是:
訪問通道:
join順序:
join方法:

full-table scans:表大表小。2萬資料量
row id scans:
index scans:
cluster scans:
hash scans:

全表掃描什麼時候用?
缺乏索引,大量的資料(4%),小表


1 產生連線順序的列表
nested loop joins(連個小表關聯,適合小表):
兩個表中其中的一個作為外表被定義(或驅動表)
另一個表叫做內部表
外部表的每一個行,在內部表中所有匹配的行被找回。

use_nl(table1 table2) hint 被使用


什麼時候用hash joins?
大量的資料需要被加入
大部分表需要被加入
使用use_hash hint.

sort_merge join:不大不小的表,介於nested loop joins 和 hash_join之間

什麼時候sort_merge joins被使用:
連線條件不是一個同等連線
排序對於其他操作是必須的

[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/24214296/viewspace-1035403/,如需轉載,請註明出處,否則將追究法律責任。

相關文章