，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！

id="一问题背景不寻常的cpu告警">一、问题背景：不寻常的CPU告警

近日，一位在医院工作的朋友找到我，说他们核心HIS系统的CPU使用率突然攀升至40%，而历史水平一直在20%左右，希望我能帮忙排查。

凭借经验，我判断这很可能是一个典型的SQL性能问题。

果不其然，从分析到解决，整个过程不到10分钟。

本文将完整复盘我的分析思路，希望能为大家提供一个高CPU消耗场景下的性能优化实战参考。

接到问题后，我首先请朋友帮忙执行top命令，获取CPU使用率的详细分解。

单纯一个“40%”的指标过于笼统，我们需要深入分析CPU时间的具体去向。

Cpu(s):

space)：用户空间程序占用的CPU百分比。

在我们的场景中，这主要指向Oracle数据库进程。

sy

space)：内核空间占用的CPU百分比，通常为操作系统内核、驱动等消耗。

wa

从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)

在当前大内存服务器普及的背景下，这种“高CPU、低IO”的性能问题正变得越来越普遍。

明确了方向后，我让朋友运行诊断脚本，重点关注处于ON

CPU状态的会话及其执行的SQL。

很快，我们就锁定了罪魁祸首，并通过关联v$active_session_history视图，获取了其执行计划和资源消耗情况。

****************************************************************************************
PLAN
****************************************************************************************
SQL_ID
-------------------------------------
SELECT
ID,JK,ZJ,YWRQ,REQJSON,MESSAGEDRGS,RESPJSON,ISUPLOAD,MARK,CREATED
FROM
------------------------------------------------------------------------------------
Operation
------------------------------------------------------------------------------------
SELECT
------------------------------------------------------------------------------------
Predicate
---------------------------------------------------
filter(("ZJ"=:2
FULL）。
CPU(92037)(100%)指标显示，几乎100%的成本都消耗在CPU上。
这完美印证了我们之前的判断。
为了进一步确认创建索引的必要性，我们用数据说话。
通过分析历史执行记录，我们得到了更精确的性能指标：
(每次执行返回行数)：接近1。
说明该查询非常高效，每次只返回极少数记录。

PRE

45万。

为了找出1行数据，却扫描了45万个数据块，这是典型的低效查询。

PRE

(每次执行CPU耗时)：约50秒。

巨大的CPU消耗完全源于海量的逻辑读。

数据不会说谎，全表扫描导致了“高逻辑读、低返回行”的性能灾难，创建索引势在必行。

那么，应该在哪一列上创建索引呢？

WHERE子句涉及JKCODE,

ZJ,

MARK四列。

我们通过查询数据字典来分析这些列的选择性（selectivity）。

COLUMN

----------------------------------------

------------

DISTINCT列显示了每列的唯一值数量。

可以看到，ZJ列的唯一值数量（2,076,160）非常接近表的总行数（2,264,030），具有极高的选择性。

因此，在ZJ列上创建索引是最佳选择。

id="三解决方案在线创建索引">三、解决方案：在线创建索引

考虑到这是在线业务系统，为避免影响正常运行，我们采用ONLINE方式创建索引。

索引创建后，效果立竿见影。
系统CPU使用率迅速回落至正常水平。
Cpu(s):
经了解，这两条问题SQL都源于一个新上线的业务模块。
这次“小事故”也暴露了一个普遍存在于许多企业的典型问题：业务上线前缺乏充分的性能测试和SQL审核。
这个案例虽然简单，但其反映的问题却值得我们深思。
在此，我提出几点建议，希望能引起开发者、DBA和项目管理者的重视：
建立SQL审核制度：任何新功能或SQL变更上线前，都应由DBA或资深开发人员进行审核（Code
Review）。
重点关注查询是否使用了合适的索引、是否存在潜在的全表扫描、以及连接逻辑是否最优。
性能测试左移：不要把性能测试推到上线前的最后一环。
开发人员在开发阶段就应该关注SQL性能，利用EXPLAIN
PLAN分析执行计划，并在开发库中进行小规模的压力测试。
强化“数据导向”的优化思维：性能优化不能仅凭感觉。
要善于利用数据库提供的性能视图（如AWR,
ASH）和诊断工具，用数据定位瓶颈，用数据验证优化效果。
培养开发人员的数据库意识：开发人员是SQL的生产者，他们的代码质量直接决定了数据库的健康状况。
企业应定期组织培训，提升开发团队的数据库基础知识，让他们理解索引原理、执行计划、事务隔离等核心概念。
幸运的是，强大的硬件和稳健的Oracle数据库为许多未经严格审查的业务提供了缓冲。
但技术债终有需要偿还的一天。
建立规范的开发、测试和上线流程，才是保障系统长期稳定、高效运行的根本之道。
------------------作者介绍-----------------------
姓名：黄廷忠
(https://blog.csdn.net/wwwhtzpw)
博客园地址:
(https://www.cnblogs.com/www-htz-pw)