CPU Time 可高于 Elapsed Time，因后者是时钟跨度总和，前者是多核并行下各CPU时间累加值；需结合ASH、执行计划及OS指标综合判断是否真CPU瓶颈。
CPU Time 不可能高于 Elapsed Time——这是 Oracle AWR 报告中一个明确的约束条件。如果你在报告里看到某条 SQL 的 CPU Time (s) 数值大于 Elapsed Time (s)，那一定不是真实现象，而是数据解读或展示层面的误读。
为什么你会“看到”CPU Time > Elapsed Time
AWR 报告中的 CPU Time 和 Elapsed Time 都是累加值，但统计口径不同：
-
Elapsed Time是该 SQL 在采样周期内所有执行的总耗时（wall-clock 时间总和），单位秒 -
CPU Time是这些执行所占用 CPU 的总时间（所有 CPU 核心上累计的 busy 时间），单位也是秒
在单核系统上，CPU Time ≤ Elapsed Time 恒成立；但在多核系统中，多个会话/执行并行消耗 CPU，CPU Time 可以轻松超过 Elapsed Time —— 这不是错误，是并行性的自然体现。
例如：一条 SQL 并发执行 8 次，每次用掉 1 个 CPU 核心 100ms，则：
-
Elapsed Time≈ 100ms（从第一次开始到最后一次结束的时钟跨度） -
CPU Time= 8 × 100ms = 800ms
AWR 报告里显示的其实是汇总后的累计值（比如 60 分钟快照内所有执行的 CPU Time 总和），所以数值远超 Elapsed Time 完全正常。
真正要警惕的是 CPU Time 占 DB Time 的比例异常高
单独看某条 SQL 的 CPU Time 绝对值没有意义，关键看它在整体负载中的占比：
- 如果某 SQL 的
CPU Time占总DB Time> 15%，且Executions稳定高位，大概率是 CPU 密集型瓶颈 - 对比
SQL ordered by CPU Time和SQL ordered by Elapsed Time：前者反映“谁吃光了 CPU”，后者反映“谁拖长了用户等待”——两者重合度低，说明问题不在 SQL 逻辑本身，而在并发、解析或锁争用 - 检查
Parse Time (s)和Hard Parse Count：若硬解析频繁，CPU Time会虚高，实际不是执行慢，而是反复做语法/语义检查
如何验证是不是真 CPU 瓶颈而非统计假象
别只盯着 AWR 报告顶部的数字，下钻看三处：
- 查
v$active_session_history：SELECT event, p1text, p2text FROM v$active_session_history WHERE sql_id = 'xxx' AND sample_time > SYSDATE-1/24 AND session_state = 'ON CPU'—— 如果大量样本落在ON CPU，才是真忙；如果集中在latch: shared pool或cursor: pin S wait on X，就是共享池争用 - 看执行计划里是否有全表扫描 + 高
Buffer Gets：这种组合常导致 CPU 空转（大量逻辑读+无索引过滤） - 对比
DB CPU在Time Model Statistics中的占比：若DB CPU占DB Time> 70%，且 Top Events 里没出现resmgr:cpu quantum，才说明硬件级 CPU 真饱和
最常被忽略的一点：AWR 中的 CPU Time 不包含后台进程（如 CKPT、ARCH）开销，也不包含操作系统层的调度延迟。你看到的“高 CPU”，可能只是前台会话在等 latch 或 mutex，而 CPU 实际处于空闲状态——得结合 OS 层 vmstat 或 top 的 %us 和 %sy 对照着看。
