1 查看AWR報告
打開報告以后，可以看到報告的組成部分的鏈接：
點擊SQL Statistics就可以直接跳轉到SQL 執行統計部分。
1.1 SQL ordered by Elapsed Time部分：
在這個部分，主要統計的是整體執行時間的top sql。排列順序是按照sql總體執行時間排序，其中：
Elapsed Time (s)= Executions* Elap per Exec (s) Elapsed Time (s) = sql 整體運行時間 Executions = sql執行次數 Elap per Exec (s) = sql單次執行時間
我們應該重點關注“Elap per Exec (s)”列，因為sql總體執行時間對於我們來說沒有太大意義，有可能此sql執行次數很多，單次執行並不長，從而整體執行時間較長。
如果想查看此sql的具體語句，可以點擊“SQL Id”進行查看。
下面我們來看一個例子，
一般在OLTP系統中，普通的業務處理的SQL 單次執行在幾毫秒就會返回，但是上面用紅色標注的sql都達到幾秒或者幾十秒，所以這些sql是重點優化對象。
當然也有一些特殊的語句執行時間教長，這些sql很多都是批量處理的，比如刪除過期數據之類的。
1.2 SQL ordered by CPU Time部分：
在這個部分，主要統計的是SQL占用cpu時間的top sql。排列順序是按照sql占用CPU時間排序，其中：
CPU Time (s)= Executions* CPU per Exec (s) CPU Time (s) = sql 占用cpu時間 Executions = sql執行次數 CPU per Exec (s) = sql單次執行占用CPU時間
我們應該重點關注“CPU per Exec (s)”列看是否單次執行sql占用CPU時間過長。
如下圖所示：
在實際現網問題處理過程中，可以不用關注此統計項，可以用“SQL ordered by Gets”統計項代替。
1.3 SQL ordered by Gets部分：
在這個部分，主要統計的是SQL邏輯讀的次數。啥是邏輯讀呢？我們執行查詢的時候，頻繁查詢的數據會緩存到數據庫的高速緩存區中，再次查找這些數據的時候就直接從內存中讀取，不需要從物理文件中讀取，這樣會大大提高查詢的速度。在內存中查找數據的時候，如果能走正確的索引，則在3-100個左右的邏輯I/O之內就會將數據查詢出來，如果系統中出現單次邏輯讀遠遠超過100的SQL，這些SQL都需要進行優化。如果邏輯I/O次數過多，則會消耗更多的CPU， 一般“SQL ordered by CPU Time”和“SQL ordered by Gets”是一一對應的，是一個因果的關系，所以CPU過高，則重點關注SQL ordered by Gets部分即可。
其中：
Buffer Gets = Executions* Gets per Exec Buffer Gets = sql 總共所用邏輯I/O Executions = sql執行次數 Gets per Exec = sql單次執行邏輯I/O次數
我們應該重點關注“Gets per Exec”列看是否邏輯讀過高。
如下圖所示：
可以看到所有的sql都有些問題，但是我們應該優先優化單次邏輯讀過高，而且占用整體邏輯讀百分比（%Total）的這些sql，也就是前三個SQL。
可以看到“SQL ordered by Gets”和 “SQL ordered by CPU Time”的兩個圖都差不多，所以一般只需要看一個“SQL ordered by Gets”即可。
1.4 SQL ordered by Reads：
在這個部分，主要統計的是SQL物理讀的次數。啥是物理讀呢？我們執行查詢的時候，如果在內存中找不到所需的數據，則會直接在物理文件中讀取，則在3-100個左右的物理I/O之內就會將數據查詢出來，如果系統中出現單次物理讀遠遠超過100的SQL，這些SQL都需要進行優化。如果物理I/O次數過多，則會導致SQL執行效率非常低下，同時會導致磁盤I/O過高影響系統問題運行。磁盤I/O過高，則需重點關注SQL ordered by Reads部分。
其中：
Physical Reads = Executions* Reads per Exec Physical Reads = sql 總共所用物理I/O Executions = sql執行次數 Reads per Exec = sql單次執行物理I/O次數
我們應該重點關注“Reads per Exec”列看是否單次物理讀過高。
如下圖所示：
可以看到大部分sql都有些問題，但是我們應該優先優化單次物理讀過高，而且占用整體物理讀百分比（%Total）的這些sql。可以看到第一個sql單次物理讀很高，而且占所有物理讀的99.55%， 分析后發現所查的表沒有加相應的索引。加上索引以后整個系統的I/O立馬就下來了，得到了質的提升。