AWR报告中“CPU利用率过高”需核查DB CPU绝对值、DB Time占比、主机CPU使用率三者匹配性；DB CPU高但Top 5等待事件为空，表明瓶颈在纯CPU计算型操作；需排除硬解析、LMS非实时调度、物化视图集中刷新等伪装因素。
AWR报告里“CPU利用率过高”不是一句模糊警告，而是必须拆开看三个数：DB CPU绝对值、DB Time占比、主机级CPU使用率——三者不匹配时，90%的所谓“CPU高”根本不用动SQL。
DB CPU高但Top 5等待事件空白，说明瓶颈在纯计算
JSON_VALUE、JSON_EXISTS、正则函数、大量CASE WHEN、复杂PL/SQL循环——这些操作不触发I/O或锁等待，只吃CPU。AWR的“Top 5 Timed Foreground Events”页面一片风平浪静，但DB CPU占DB Time 65%，且DB CPU绝对值超过（CPU核数 × 快照秒数 × 0.8），就是典型信号。
- 查
DB CPU绝对值：报告开头的“DB Time”和“DB CPU”两行，直接看秒数，别只扫百分比 - 对比主机CPU：用
vmstat 1 5或top确认%us+%sy是否持续＞85%，否则可能是其他进程抢资源 - 过滤假高：如果
DB CPU / (Host CPU (CPUs) × 快照时长)＜ 0.5，基本可排除数据库层真实过载
SQL ordered by CPU Time里总耗时高 ≠ 要优化
总CPU时间排第一的SQL，可能只是执行了5000次、单次才2ms的轻量语句；真正该盯的是单次CPU消耗＞1秒、且执行频次＞10次/小时的SQL。
- 忽略
EXECUTIONS = 0但CPU_TIME_SEC > 0的行——这是游标异常终止残留的脏数据 - 优先筛：
CPU per Exec (s) > 1且Executions > 10；或CPU per Exec (s) > 10（哪怕只执行1–2次） - 点进SQL详情页，检查
PLAN_HASH_VALUE是否稳定——漂移说明某次劣化执行拉高均值，不代表常态
硬解析多、LMS没跑RT模式、物化视图刷新，都伪装成“CPU高”
AWR里Parse CPU和Parse Elapsed差值极小，且v$sqlarea.parse_calls / executions ≈ 1，就是硬解析在榨干CPU；RAC环境下LMS进程cls显示ts而非ff，说明没跑实时调度，GC重试会把%sy顶到80%+；物化视图定时刷新若没错开业务高峰，也会在快照窗口内集中爆发。
- 查硬解析：运行
SELECT sql_id, parse_calls, executions FROM v$sqlarea WHERE parse_calls > 100 AND executions > 0 ORDER BY parse_calls/executions DESC - 验LMS调度：用
ps -eo pid,comm,cls,pri,rtprio,%cpu --sort=-%cpu | grep LMS，cls列必须是ff或rr - 抓定时任务：查
dba_scheduler_jobs和dba_mviews，结合快照时间比对刷新窗口
最常被跳过的动作，是确认AWR快照本身是否覆盖了问题时段——dba_hist_snapshot里查不到end_interval_time，后面所有分析都是空中楼阁。
