sql tuning

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被使用：
連線條件不是一個同等連線
排序對於其他操作是必須的