mysql awr报告怎么看_如何使用AWR报告查看问题之所在(转)

不念不忘少年蓝@ 2022-10-25 15:24 365阅读 0赞

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”进行查看。

下面我们来看一个例子，

![JpsrfOFTVWMAAAAASUVORK5CYII=][JpsrfOFTVWMAAAAASUVORK5CYII]

一般在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时间过长。

如下图所示：

![AwAAAIjlAjQAAAAACwEaAAAAqECABgAAACoQoAEAAIAKBGgAAACgAgEaAAAAqECABgAAACr8AfZ6nrD4TKt9AAAAAElFTkSuQmCC][JpsrfOFTVWMAAAAASUVORK5CYII]

在实际现网问题处理过程中，可以不用关注此统计项，可以用“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”列看是否逻辑读过高。

如下图所示：

![Pw8aOTKxRZdUAAAAAElFTkSuQmCC][JpsrfOFTVWMAAAAASUVORK5CYII]

可以看到所有的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”列看是否单次物理读过高。

如下图所示：

![QQjgAAAAAAAAAA4QgAAAAAAAAEwScc7wAAAAAAAAAAgVM4AgAAAAAAAIAHEI4AAAAAAABAECAcAQAAAAAAgCBAOAIAAAAAAABB+P8BDhH5AVK7lEIAAAAASUVORK5CYII=][JpsrfOFTVWMAAAAASUVORK5CYII]

可以看到大部分sql都有些问题，但是我们应该优先优化单次物理读过高，而且占用整体物理读百分比(%Total)的这些sql。可以看到第一个sql单次物理读很高，而且占所有物理读的99.55%， 分析后发现所查的表没有加相应的索引。加上索引以后整个系统的I/O立马就下来了，得到了质的提升。

[JpsrfOFTVWMAAAAASUVORK5CYII]: