利用Oracle AWR SQL执行次数判断业务逻辑合理性

先纠正一个常见误区：AWR 里的 SQL_EXECUTIONS 数值偏高，并不直接等同于业务调用量就很大。如果直接按该字段降序排列，最先出现的往往是心跳检测、日志写入、SELECT 1 FROM DUAL 这类基础设施类语句——这些如同噪音一般，将真实的业务热点完全淹没。要准确评估业务逻辑是否合理，关键并非统计“执行了多少次”，而是深入分析“为何会执行这么多次”。

首先过滤已知的低价值 SQL 语句

在 AWR 的高频 SQL 列表中，大量语句来自应用框架或中间件自动生成的“干扰噪音”。如果不将这些杂质先行剔除，后续的分析工作将徒劳无功。

• 借助 SQL_TEXT LIKE 匹配典型模式：'SELECT 1%'、'INSERT INTO LOG_%'、'UPDATE %_STATUS'
• 排除 MODULE = 'JDBC Thin Client' 且 PROGRAM 包含 'ConnectionPool' 或 'HealthCheck' 的记录
• 跳过 FORCE_MATCHING_SIGNATURE = 0 的短 SQL（例如 COMMIT、ROLLBACK），这类语句无法有效聚合，自身也不反映业务逻辑

利用 EXECUTIONS_DELTA 与 FORCE_MATCHING_SIGNATURE 对齐业务语义

SQL_ID 的粒度过于细致——MyBatis 拼接 IN 列表、JPA 动态 WHERE 条件时，即便查询的是同一张表与同一字段，SQL_ID 也会完全不同。真正能够代表“一个业务动作”的标识，实际上是 FORCE_MATCHING_SIGNATURE。

• 查询 DBA_HIST_SQLSTAT 时必须 GROUP BY FORCE_MATCHING_SIGNATURE，随后 SUM(EXECUTIONS_DELTA) 进行汇总
• JOIN DBA_HIST_SQLTEXT 获取任意一条代表性文本，通过人工方式识别业务意图（例如看到 WHERE status = :1，即可判断这是“查询状态”的操作）
• 若数据库未启用 cursor_sharing = FORCE，部分 SQL 签名为空，此时可退而采用正则提取：统一将以 FROM orders WHERE user_id = 开头的语句归类为“用户订单查询”

结合 ASH 定位真实的调用上下文

AWR 提供的是每小时一次的快照数据，根本无法捕捉“30 秒内执行了 70 次”这类瞬时高频行为——比如每秒查询 JUDGE_TASK WHERE STATUS='0' 的任务轮询。这种节奏型的执行模式，只有 DBA_HIST_ACTIVE_SESS_HISTORY 才能清晰呈现。

• 查询 SQL_ID 对应的活跃会话，重点关注 MODULE、ACTION、CLIENT_ID（如果应用层已设置相关参数）
• 在时间维度上，使用 SAMPLE_TIME 聚合分钟级别的执行频次，确认是否为固定周期触发（例如每 30 秒触发一次）
• 如果 PLSQL_ENTRY_OBJECT_ID 不为空，JOIN DBA_OBJECTS 即可直接定位到具体是哪个存储过程或程序包在驱动这条 SQL

执行频次异常的典型信号与判断方法

业务逻辑不合理的常见表现，往往是“单次业务请求引发 N 次相同 SQL 执行”，而非“N 次业务请求各自触发一次 SQL”。这类问题通过肉眼即可初步判断：

• 同一条 SQL 在 30 分钟内执行次数超过 10 万次，但对应业务表每天仅新增几十条数据（例如 JUDGE_TASK 表仅有 60 行记录，却每天被查询 600 万次）
• EXECUTIONS_DELTA 与 ELAPSED_TIME_DELTA 的比值极低（执行 10 万次总耗时仅需几秒），说明 SQL 本身非常轻量，高频执行的根源在于轮询或重试逻辑
• 物理读与执行次数的比值正常（PHYSICAL_READS / EXECUTIONS < 10），但逻辑读与执行次数的比值极高（>5000），这大概率是索引全扫描配合 ROWNUM 截断所致，未走最优执行路径

归根结底，真正的难点不在于统计执行次数，而在于将 EXECUTIONS_DELTA 准确映射回具体的业务动作。针对每一个 FORCE_MATCHING_SIGNATURE 对应的频次，都应该能够清晰说明：“这是用户下单时查询库存、这是定时任务清理归档数据、这是接口幂等性校验”。否则，数据再精准，也难以落地转化为有效的优化行动。