AWR中SQL的CPU Time占比远高于Elapsed Time，是因CPU Time为所有并行进程CPU耗时总和，而Elapsed Time为客户端感知的端到端耗时；例如并行度8、各进程跑2秒CPU，则CPU Time=16秒，Elapsed Time≈2.1秒，占比达76%。
AWR报告里某条SQL的CPU Time占比远高于它的Elapsed Time（比如CPU占95%，但Elapsed才3秒），这不是数据错乱，而是典型“高CPU密度型”SQL的信号——它没在等IO或锁，而是在纯算力上猛踩油门。这类SQL往往不慢，但一跑就是几十个并发，把CPU吃干抹净。
为什么CPU Time会显著高于Elapsed Time？
这是常见误解点：CPU Time是所有并行服务器进程（包括PX worker）消耗的CPU总和；Elapsed Time是客户端感知的端到端耗时。例如一条并行度为8的SQL，每个PX进程各跑2秒CPU，总CPU Time = 16秒，但Elapsed Time可能只有2.1秒——AWR里就会显示CPU占比高达76%（16 / 2.1）。所以不是“单次执行很慢”，而是“单位时间吞吐CPU能力极强”。
- 查确认是否并行：看AWR中该SQL的
SQL ordered by CPU页，“PX Servers Executions”列是否 > 0 - 看执行计划：是否存在
PX COORDINATOR、PX SEND、PX RECEIVE等操作符 - 注意
DB CPU(s)在Load Profile里是否接近DB Time(s)——如果是，说明数据库几乎全在算，没卡在IO或锁上
如何快速定位是不是并行失控？
别只盯SQL_ID，先查它在问题时段是否被反复触发、是否被多个会话同时执行。用ASH补位比AWR更准，因为AWR只给聚合值，ASH能还原时间线：
- 执行
SELECT sql_id, session_id, sql_exec_start, event, p1text, p1 FROM dba_hist_active_sess_history WHERE sql_id = '&sql_id' AND sample_time BETWEEN ... AND ... ORDER BY sample_time; - 重点看
event是否长期为ON CPU（不是db file sequential read之类） - 检查
p1text和p1：若为server#且值 > 0，基本坐实是PX worker在干活 - 对比
v$px_session里的server_set和degree，确认实际并行度是否远超业务需要（比如设了32，但数据量只够4并行）
调优优先级：从配置层砍掉冗余并行，再动SQL
盲目改SQL执行计划常无效，因为问题根子在“不该并行的被并行了”。优先检查三层控制开关：
-
PARALLEL_DEGREE_POLICY是否为AUTO？若是，Oracle可能对小表也自动启并行（尤其12c+），建议临时设为MANUAL做验证 - 该SQL是否带
/*+ parallel(t, 8) */提示？开发写死的hint比表级设置更难发现，用SELECT sql_text FROM v$sql WHERE sql_id = '&sql_id'直接看原始文本 - 表本身是否有
PARALLEL属性？查SELECT degree FROM dba_tables WHERE table_name = 'XXX';，若非零，且业务无批量ETL需求，应ALTER TABLE xxx NOPARALLEL; - 最后才是执行计划：如果确认必须并行，检查是否因缺少索引导致大量
SORT AGGREGATE或HASH JOIN——这两类操作在并行下CPU飙升最快
容易被忽略的硬伤：物化视图刷新与JOB隐式并行
很多团队查遍SQL却漏掉后台任务。AWR里SQL ordered by CPU排名靠前的SQL_ID，可能根本不是应用发的，而是DBMS_MVIEW.REFRESH或DBMS_SCHEDULER触发的。这类任务默认继承系统并行度，且不走应用连接池，极易失控：
- 查
dba_scheduler_jobs里最近执行的JOB，过滤job_action含refresh或mview的记录 - 查
dba_mview_refresh_times，确认物化视图刷新频率是否和CPU波峰完全重合（比如每整点刷一次，每次刷3分钟） - 关键动作：用
SELECT sql_id, program_id, program_action FROM dba_scheduler_job_run_details WHERE actual_start_date BETWEEN ... AND ...;反查JOB运行时的真实SQL_ID
真正棘手的从来不是单条SQL怎么写，而是你不知道它正被谁、以什么并行度、在什么时间点批量唤醒。AWR只告诉你“谁吃了CPU”，ASH和调度视图才告诉你“谁按下了启动键”。
