如何分析AWR中的Top SQL_根据CPU与物理读定位核心慢查询

AWR中真正吃CPU的SQL需关注累计CPU消耗而非单次耗时，应结合Elapsed Time与Executions计算平均耗时，并检查Buffer Gets/Physical Reads比值、执行计划合理性、Child Number差异及绑定变量影响。

怎么看AWR里真正吃CPU的SQL

打开AWR报告，很多人会直奔Top SQL by CPU Time部分，以为排名第一的就是“罪魁祸首”。但这里有个常见的误区：排名靠前的，可能只是单次执行最慢的“大家伙”，而不是真正让CPU持续承压的“主力军”。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

举个例子就明白了。一条SQL排在榜首，单次执行耗时200毫秒，听起来挺慢，但它每秒只跑一次。另一条SQL，单次执行飞快，只要4毫秒，可它每秒要执行50次。算算总账，后者累计消耗的CPU时间是前者的10倍，但它很可能因为单次耗时太短，根本挤不进前五名。所以，关键不是揪出“谁最慢”，而是要找到“谁最累”——也就是累计开销最大的那个。

具体怎么操作？看这里：

• 在SQL ordered by CPU Time部分，别光盯着CPU Time一栏。要把Elapsed Time (s)和Executions这两列结合起来看，手动算一下平均单次耗时（Elapsed Time / Executions）。再结合执行频次，你就能判断这条SQL是偶尔“爆发”一下，还是在持续地“细水长流”式消耗资源。
• 特别留意那些Buffer Gets（逻辑读）数值远高于Physical Reads（物理读）的SQL。这通常意味着它是逻辑读密集型操作，数据都在内存里，但SQL本身可能因为缺失索引或走了全表扫描，需要在CPU上进行海量的数据块处理。这种SQL就像在CPU上“空转”，是消耗CPU的典型嫌疑犯。
• 还有一个硬指标：如果某条SQL的CPU Time占整个数据库DB Time的比例超过了15%，并且它的Executions（执行次数）一直维持在高位，那基本可以把它锁定为需要优先调查的根因候选了。

物理读高但CPU不高？先确认是不是真的慢

再看Top SQL by Physical Reads这个榜单，它反映的是I/O压力。但务必记住：物理读高，不等于响应慢，更不等于它当前就是问题。

这里需要区分场景。比如，一条后台运行的报表SQL，需要全表扫描10GB的历史数据，它的物理读肯定高，执行时间也长。但这种批量作业本身预期就是慢的，可能并非当前性能瓶颈。相反，一条高频的OLTP语句，每次只期望读取几十行，却频繁触发物理读，导致响应时间抖动，这才是真正要命的、需要立刻关注的问题。

所以，看到高物理读的SQL，得接着往下分析：

• 对照查看Rows Processed（处理行数）和Executions（执行次数）。可以计算一个粗略的比值：Physical Reads / Rows Processed。如果这个比值大于10，意味着平均为了获取一行数据，要读超过10个数据块。这几乎可以肯定存在索引缺失，或者统计信息已经严重过时，导致优化器选错了执行路径。
• 仔细检查SQL的执行计划（SQL Profile）。如果计划中间出现了TABLE ACCESS FULL（全表扫描），但查询条件明明有字段，那就要怀疑是不是该字段没建索引，或者索引的选择性太差（比如在状态字段status IN ('A','B','C')上建索引，过滤效果不佳）。
• 另外，关注一下等待事件。如果这条SQL的等待事件中Direct Path Read占比很高，说明Oracle绕过了Buffer Cache直接读取数据。这对于处理大数据集的排序或并行查询来说是正常操作，但如果在短平快的OLTP事务里频繁出现，那就值得深究了。

用awrsqrpt.sql快速定位具体SQL文本和执行计划

AWR报告虽然列出了SQL_ID和关键指标，但它不显示完整的SQL文本和具体的执行计划。光看数字，就像只知道病人发烧，却不知道病因，没法对症下药。

这时候，就需要请出更详细的诊断工具了。方法很直接：

• 连接到数据库服务器，运行脚本：$ORACLE_HOME/rdbms/admin/awrsqrpt.sql。根据提示，输入你关注的SQL_ID、对应的快照范围，输出格式建议选html，阅读起来更方便。
• 生成的详细报告里，Execution Plan（执行计划）部分是重中之重。重点比对计划中的Rows（优化器预估返回的行数）和A-Rows（实际返回的行数）。如果两者相差超过一个数量级（比如预估100行，实际返回1万行），那几乎可以断定是统计信息不准，导致优化器“看走了眼”。这时，赶紧安排DBMS_STATS.GATHER_TABLE_STATS更新统计信息是当务之急。
• 观察执行计划的连接方式。如果发现是NESTED LOOPS（嵌套循环），并且外层驱动表返回了百万行，内层表却没有走索引，这就是典型的“循环放大”问题。性能损耗会成倍增加。优化方向通常是考虑为内层表添加合适的索引，或者尝试改写SQL，引导优化器使用HASH JOIN（哈希连接）。

别忽略Child Number和Bind Peek的影响

事情到这里还没完。一个更隐蔽的陷阱在于：同一个SQL_ID，可能对应多个不同的Child Number（子游标）。每个子游标可能有着完全不同的执行计划。而AWR报告默认汇总的，往往是主游标（Child Number = 0）的数据。真正拖慢系统的，可能是Child Number = 3的那个子游标，它因为使用了某个特定的绑定变量值，走上了一条错误的执行路径。

这就是绑定变量窥探（Bind Peek）可能带来的问题。所以，排查时必须深入到这一层：

• 查询v$sql动态性能视图时，务必带上child_number和is_bind_sensitive字段。例如：SELECT sql_id, child_number, is_bind_sensitive, plan_hash_value FROM v$sql WHERE sql_id = 'xxx'。如果is_bind_sensitive显示为'Y'，就说明这条SQL对绑定变量的值很敏感。
• 对于绑定变量敏感的SQL，必须用DBMS_XPLAN.DISPLAY_CURSOR(sql_id, child_number)逐个检查每个子游标的实际执行计划。你可能会发现，传入值‘A’时它高效地使用了索引，而传入值‘B’时却变成了可怕的全表扫描。
• 如果确认是Bind Peek导致的计划不稳定，临时解决方案可以在SQL中添加Hint：OPT_PARAM('_optim_peek_user_binds' 'false')来关闭窥探。长期的、更稳健的解决方案，则是考虑升级数据库版本（12c及以上），利用自适应执行计划或SQL计划基线（SQL Plan Baseline）来固化最优的执行计划。

说到底，真正的挑战往往不在于找到AWR报告里排名第一的SQL，而在于厘清同一个SQL_ID背后，不同Child Number的千差万别，以及绑定变量是如何在幕后悄然改变执行路径的。这些至关重要的细节，都藏在v$sql和DBMS_XPLAN这些更底层的视图和工具里，不会直接呈现在AWR报告的摘要页面上。