sql_executions高≠业务调用多，因其统计oracle执行次数而非业务请求次数；需用force_matching_signature聚合语义相同sql，过滤心跳、轮询等低价值sql，并结合ash的module/action及plsql_entry_object_id定位真实业务频次。
AWR里SQL ordered by Executions偏高，基本不是业务请求量暴增，而是大量低价值SQL（心跳、轮询、日志写入）在刷执行次数——直接按这个字段排序会掩盖真实业务热点。
为什么Executions高不等于业务调用多
Oracle的EXECUTIONS统计的是SQL语句被数据库执行的次数，不是应用层发起的业务请求次数。一条业务操作背后可能触发10次SELECT 1 FROM DUAL、5次状态轮询、3次日志插入，这些都会计入Executions，但和核心逻辑无关。
- MyBatis动态SQL、JPA批量更新、Spring Retry机制都容易导致单次业务产生数十次重复执行
-
FORCE_MATCHING_SIGNATURE = 0的短SQL（如COMMIT、ROLLBACK）无法聚合，但执行频次天然高 - MODULE为
JDBC Thin Client且PROGRAM含HealthCheck或ConnectionPool的记录，99%是框架自检行为
怎么过滤掉干扰项，定位真实业务SQL
别只看AWR报告里的默认列表。得进DBA_HIST_SQLSTAT手动聚合：
- 用
FORCE_MATCHING_SIGNATURE代替SQL_ID做GROUP BY，把WHERE status = :1这类语义一致的SQL归为一类 - 加WHERE条件排除已知噪音：
SQL_TEXT NOT LIKE 'SELECT 1%'、SQL_TEXT NOT LIKE 'INSERT INTO LOG_%' - JOIN
DBA_HIST_ACTIVE_SESS_HISTORY查MODULE和ACTION，确认是否来自OrderService.process()这类真实业务模块 - 如果
PLSQL_ENTRY_OBJECT_ID非空，JOINDBA_OBJECTS能直接定位到驱动SQL的存储过程名
Executions突增时真正要盯的三个信号
单纯数值高不用慌，但出现以下组合就得动手：
- 同一
FORCE_MATCHING_SIGNATURE在30分钟内EXECUTIONS_DELTA > 100000，而对应业务表当天只新增几十条数据（比如JUDGE_TASK表每天10条，但SQL执行了8万次） -
SQL ordered by Executions榜首的SQL，在SQL ordered by Elapsed Time里完全不见踪影——说明它快但太“碎” - 结合ASH发现该SQL的
SAMPLE_TIME呈现严格周期性（如每30秒±200ms执行一次），基本可断定是轮询任务没加缓存或没改异步
最常被忽略的一点：AWR快照粒度是1小时，根本抓不住秒级高频行为。Executions异常必须搭配DBA_HIST_ACTIVE_SESS_HISTORY按分钟聚合验证，否则你优化的可能只是幻觉。
