如何根据Oracle AWR中的SQL执行次数判断业务逻辑的合理性

AWR中SQL_EXECUTIONS高不直接反映业务调用多，因其统计Oracle执行次数而非业务请求次数；需结合FORCE_MATCHING_SIGNATURE聚合语义相同SQL、过滤低价值SQL、利用ASH分析MODULE/ACTION上下文及PLSQL_ENTRY_OBJECT_ID定位真实业务频次。

SQL_EXECUTIONS 高 ≠ 业务调用多，直接按这个字段排序会把心跳 SQL、日志插入、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 对应的频次，要能说清：“这是用户下单时查库存、这是定时任务清理归档、这是接口幂等校验”。否则数字再准，也落不了地。