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立马就下来了，得到了质的提升。
