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_TEXTLIKE 匹配：'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非空，JOINDBA_OBJECTS能直接定位到是哪个存储过程/包在驱动这条 SQL
执行频次异常的典型信号
业务逻辑不合理，往往表现为“单次业务请求引发 N 次相同 SQL”，而不是“N 次业务请求各触发一次 SQL”。这类问题肉眼可判：
- 同一条 SQL 在 30 分钟内执行超 10 万次，但对应业务表每天只新增几十条数据（如
JUDGE_TASK表仅 60 行，却每天被查 600 万次） -
EXECUTIONS_DELTA和ELAPSED_TIME_DELTA比值极低（比如执行 10 万次，总耗时才几秒），说明 SQL 本身很轻量，高频纯属轮询或重试逻辑 - 物理读/执行比值正常（
PHYSICAL_READS / EXECUTIONS ），但逻辑读/执行极高（>5000），大概率是索引全扫+<code>ROWNUM截断，没走最优路径
EXECUTIONS_DELTA 映射回业务动作。一个 FORCE_MATCHING_SIGNATURE 对应的频次，要能说清：“这是用户下单时查库存、这是定时任务清理归档、这是接口幂等校验”。否则数字再准，也落不了地。
