我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。
一、问题背景：不寻常的CPU告警
近日，一位在医院工作的朋友找到我，说他们核心HIS系统的CPU使用率突然攀升至40%，而历史水平一直在20%左右，希望我能帮忙排查。凭借经验，我判断这很可能是一个典型的SQL性能问题。
果不其然，从分析到解决，整个过程不到10分钟。本文将完整复盘我的分析思路，希望能为大家提供一个高CPU消耗场景下的性能优化实战参考。
二、性能诊断
2.1 定位CPU消耗来源
接到问题后，我首先请朋友帮忙执行top命令，获取CPU使用率的详细分解。单纯一个“40%”的指标过于笼统，我们需要深入分析CPU时间的具体去向。
Cpu(s): 45.3%us, 2.5%sy, 0.0%ni, 50.8%id, 1.1%wa, 0.0%hi, 0.3%si, 0.0%st
我们重点关注以下三项：
us(user space)：用户空间程序占用的CPU百分比。在我们的场景中，这主要指向Oracle数据库进程。sy(system space)：内核空间占用的CPU百分比，通常为操作系统内核、驱动等消耗。wa(I/O wait)：CPU等待I/O操作完成的时间百分比。
从top的输出可以看到，用户空间（us）占用了高达45.3%的CPU，而系统内核（sy）和IO等待（wa）的占比都非常低。这清晰地表明：系统的IO性能没有瓶颈，问题根源在于Oracle数据库自身消耗了过多的CPU资源。
那么，什么情况下Oracle会消耗大量CPU而IO压力不大呢？常见原因包括：
- 密集的内存运算：如大量的逻辑读（Logical Reads）、复杂的函数或表达式计算、高频的Mutex/Latch争用等。
- 低效的程序代码：如循环嵌套、无谓计算的PL/SQL或Java存储过程。
- 特定内部功能：如Oracle的In-Memory (IM) Columnar Store等。
在当前大内存服务器普及的背景下，这种“高CPU、低IO”的性能问题正变得越来越普遍。
2.2 锁定问题SQL
明确了方向后，我让朋友运行诊断脚本，重点关注处于ON CPU状态的会话及其执行的SQL。很快，我们就锁定了罪魁祸首，并通过关联v$active_session_history视图，获取了其执行计划和资源消耗情况。
****************************************************************************************
PLAN STAT FROM ASH
****************************************************************************************
SQL_ID f0kfhaa3z2p0f, child number 0
-------------------------------------
SELECT ID,JK,ZJ,YWRQ,REQJSON,MESSAGEDRGS,RESPJSON,ISUPLOAD,MARK,CREATED
TIME,MODIFIEDTIME,NOTE,JKCODE FROM HT_HTZZ_HTZPWD WHERE MARK='1'
AND (JKCODE = :1 AND ZJ = :2 AND ISUPLOAD = :3 )
Plan hash value: 1313371775
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 117K(100)| |CPU(2)(0%) |
|* 1 | TABLE ACCESS FULL| TB_HMYY_UPLOAD | 1 | 1357 | 117K (1)| 00:23:35 |CPU(92037)(100%) |
------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(("ZJ"=:2 AND "JKCODE"=:1 AND "ISUPLOAD"=:3 AND "MARK"='1'))执行计划一目了然：全表扫描（TABLE ACCESS FULL）。CPU(92037)(100%)指标显示，几乎100%的成本都消耗在CPU上。这完美印证了我们之前的判断。
2.3 量化性能瓶颈
为了进一步确认创建索引的必要性，我们用数据说话。通过分析历史执行记录，我们得到了更精确的性能指标：
PLAN CPU ELA IO ROWS WRITE GET DISK ROWS
END_TI I NAME HASH VALUE EXEC PRE EXEC PRE EXEC PER EXEC PRE EXEC PER EXEC PRE EXEC PRE EXEC PRE FETC
------ - --------------- ------------- ---------- -------- -------- -------- -------- -------- -------- -------- --------
16 09 1 HTZZ 1313371775 30 49.92s 50.09s 4.9ms .97 0 45.13W 13.3 1
16 10 1 HTZZ 1313371775 30 51.45s 51.53s .07ms .97 0 45.13W .17 1
16 10 1 HTZZ 1313371775 30 52.28s 53.37s 56.32ms 1 0 45.13W 138.93 1
关键数据解读：
ROWS PRE EXEC(每次执行返回行数)：接近1。说明该查询非常高效，每次只返回极少数记录。GET PRE EXEC(每次执行逻辑读)：高达 45万。为了找出1行数据，却扫描了45万个数据块，这是典型的低效查询。CPU PRE EXEC(每次执行CPU耗时)：约50秒。巨大的CPU消耗完全源于海量的逻辑读。
数据不会说谎，全表扫描导致了“高逻辑读、低返回行”的性能灾难，创建索引势在必行。
2.4 选择索引列
那么，应该在哪一列上创建索引呢？WHERE子句涉及JKCODE, ZJ, ISUPLOAD, MARK四列。我们通过查询数据字典来分析这些列的选择性（selectivity）。
COLUMN NUM NUM AVG LAST
NAME NL DENSITY NULLS DISTINCT BUCK COL LEN SAMPLE_SIZE HIST ANALYZED
---------------------------------------- -- ------------ ------------ -------- ----- ------------ ------------ ----- --------
ID(VARCHAR2(64)) N 0 0 2264030 1 20 2,264,030 NONE 20250711
JK(VARCHAR2(128)) Y 0 10 7 7 30 5,469 FREQU 20250711
ZJ(VARCHAR2(128)) Y 0 0 2076160 254 46 5,469 HEIGH 20250711
YWRQ(DATE(7)) Y 0 0 586496 254 8 5,469 HEIGH 20250711
REQJSON(CLOB(4000)) Y 0 0 0 0 964 2,264,030 NONE 20250711
MESSAGEDRGS(NVARCHAR2(4000)) Y 0 0 22 1 18 2,264,030 NONE 20250711
RESPJSON(CLOB(4000)) Y 0 0 0 0 244 2,264,030 NONE 20250711
ISUPLOAD(CHAR(1)) Y 0 0 2 2 2 5,469 FREQU 20250711
NUM DISTINCT列显示了每列的唯一值数量。可以看到，ZJ列的唯一值数量（2,076,160）非常接近表的总行数（2,264,030），具有极高的选择性。因此，在ZJ列上创建索引是最佳选择。
三、解决方案：在线创建索引
考虑到这是在线业务系统，为避免影响正常运行，我们采用ONLINE方式创建索引。
create index hrip.ind_HT_HTZZ_HTZPWD_1 on hrip.HT_HTZZ_HTZPWD (ZJ) online parallel 10 tablespace HTZZ;
alter index hrip.ind_HT_HTZZ_HTZPWD_1 noparallel;
四、总结与反思
索引创建后，效果立竿见影。系统CPU使用率迅速回落至正常水平。
Cpu(s): 27.1%us, 2.7%sy, 0.0%ni, 68.8%id, 1.2%wa, 0.0%hi, 0.2%si, 0.0%st
经了解，这两条问题SQL都源于一个新上线的业务模块。这次“小事故”也暴露了一个普遍存在于许多企业的典型问题：业务上线前缺乏充分的性能测试和SQL审核。
这个案例虽然简单，但其反映的问题却值得我们深思。在此，我提出几点建议，希望能引起开发者、DBA和项目管理者的重视：
-
建立SQL审核制度：任何新功能或SQL变更上线前，都应由DBA或资深开发人员进行审核（Code Review）。重点关注查询是否使用了合适的索引、是否存在潜在的全表扫描、以及连接逻辑是否最优。
-
性能测试左移：不要把性能测试推到上线前的最后一环。开发人员在开发阶段就应该关注SQL性能，利用
EXPLAIN PLAN分析执行计划，并在开发库中进行小规模的压力测试。 -
强化“数据导向”的优化思维：性能优化不能仅凭感觉。要善于利用数据库提供的性能视图（如AWR, ASH）和诊断工具，用数据定位瓶颈，用数据验证优化效果。
-
培养开发人员的数据库意识：开发人员是SQL的生产者，他们的代码质量直接决定了数据库的健康状况。企业应定期组织培训，提升开发团队的数据库基础知识，让他们理解索引原理、执行计划、事务隔离等核心概念。
幸运的是，强大的硬件和稳健的Oracle数据库为许多未经严格审查的业务提供了缓冲。但技术债终有需要偿还的一天。建立规范的开发、测试和上线流程，才是保障系统长期稳定、高效运行的根本之道。
------------------作者介绍-----------------------
姓名：黄廷忠
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)
)