单次执行快但总量慢的本质是高频低耗sql隐性积压，awr中executions_delta突增是最直接信号；v$sql的executions为易失累计值，而dba_hist_sqlstat基于快照的增量统计才真实可回溯。
单次执行快但总量慢，本质是“高频低耗”sql在积累后拖垮系统资源，awr里 executions_delta 突增就是最直接信号——不是sql变慢了，而是它被调用了几百上千次。
为什么V$SQL的EXECUTIONS不准，必须看DBA_HIST_SQLSTAT
V$SQL 中的 EXECUTIONS 是累计值，且只保留在共享池中：游标老化、内存压力、实例重启都会清零或丢失。它反映的是“当前缓存里这个SQL被执行过多少次”，不是“过去24小时真实发生了多少次”。
而 DBA_HIST_SQLSTAT 来自 AWR 快照，每小时自动采样一次（默认），EXECUTIONS_DELTA 是两次快照间的增量，不可篡改、可回溯、带时间维度。
- 如果某条SQL在
V$SQL里显示EXECUTIONS = 5，但过去一小时在 AWR 里查出SUM(EXECUTIONS_DELTA) = 1280，说明它刚被硬解析过，旧子游标已淘汰 -
DBA_HIST_SQLSTAT要和DBA_HIST_SNAPSHOT关联才能对齐时间窗口，漏掉AND M.SNAP_ID = N.SNAP_ID会导致笛卡尔积，结果虚高 - 多实例 RAC 环境下必须加
AND M.INSTANCE_NUMBER = N.INSTANCE_NUMBER，否则会跨实例错配
按小时查执行次数时，BEGIN_INTERVAL_TIME格式不能只用TRUNC
AWR 快照的 BEGIN_INTERVAL_TIME 是 TIMESTAMP 类型，直接 TRUNC(BEGIN_INTERVAL_TIME) 会丢失小时精度，导致所有同一天的快照全归到 00:00 —— 看起来像“一天只执行1次”，实际可能是每小时执行200次。
正确做法是用 TO_CHAR(N.BEGIN_INTERVAL_TIME, 'YYYY-MM-DD HH24') 或 CAST(TRUNC(N.BEGIN_INTERVAL_TIME, 'HH24') AS DATE)。
- 错误写法：
GROUP BY TRUNC(N.BEGIN_INTERVAL_TIME)→ 所有小时数据坍缩成天粒度 - 正确写法：
GROUP BY TO_CHAR(N.BEGIN_INTERVAL_TIME, 'YYYY-MM-DD HH24')→ 保留小时切片 - 注意时区：
BEGIN_INTERVAL_TIME存的是数据库服务器时区时间，不是客户端时区
EXECUTIONS_DELTA为0不代表没执行，要看是否采样覆盖了执行窗口
AWR 默认每小时采样一次（interval_size 通常为 3600 秒），如果某条SQL集中在两分钟内爆发执行了 500 次，而快照刚好在它执行前1秒和执行后1秒采集，EXECUTIONS_DELTA 就可能为 0 —— 因为它没落在两个快照之间。
这种漏采在短周期高频场景（如批处理触发、API洪峰）中很常见。
- 验证方法：查
V$SQL的LAST_ACTIVE_TIME和EXECUTIONS，对比最近几分钟是否突增 - 补救手段：临时提高 AWR 快照频率（需 DBA 权限），或启用 SQL Monitor（
/*+ MONITOR */）捕获单次执行明细 - 更可靠替代：结合应用日志 + 数据库审计（
AUDIT SELECT ON schema.table BY ACCESS），绕过 AWR 采样盲区
真正难的不是查出执行次数，而是确认这些执行是不是必要、有没有合并/缓存/批量化的空间——AWR 给你数字，但业务逻辑决定这些数字该不该存在。
