一、概述

性能优化是指在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。

二、硬件性能分析

2.1查看CPU 负载
top命令查看CPU负载

load average（系统负载）：
load average: 0.11, 0.10, 0.04 三个数值分别代表过去 1分钟，5分钟，15分钟的系统负载该值越大系统越繁忙，通常认为该值小于系统cpu核心数则认为系统负载正常。
%Cpu0~n （特定cpu核心的使用状态细分）重点关注 us(用户),sy(系统),id(空闲),wa(等待)
总结如下：
2.1.1 id 低且 us 高（如 us=80%，id=20%）：
原因：用户态程序（如应用程序、数据库）占用大量 CPU，属于 CPU 密集型负载。
排查：用 top 按 P 键排序，定位高 us 的进程（如 Java 程序、编译任务）。
2.1.2 id 低且 sy 高（如 sy=70%，id=30%）：
原因：内核态程序（如驱动、系统调用）占用大量 CPU，可能是硬件驱动异常或系统调用频繁。
排查：检查内核日志（dmesg）或用 perf 工具分析内核函数调用。
2.1.3 wa 高（如 wa=50%，id=40%）：
原因：CPU 空闲但在等待 I/O 操作（如磁盘读写、网络请求），属于 I/O 密集型负载。
排查：用 iostat -x 查看磁盘 I/O 队列（avgqu-sz）和等待时间（await），或用 iotop
定位高 I/O 进程。

2.2查看磁盘IO负载情况
iostat -x命令查看IO负载

关键指标解读
2.2.1 %util：磁盘利用率，越高代表磁盘越繁忙。
2.2.2 aqu-sz：平均队列长度，越高说明队列严重堆积（若 aqu-sz 高且 %util 高，瓶颈更严重）。
2.2.3 r_await/w_await：读/写平均等待时间（SSD 正常应低于 5ms），若较高可能由高队列或硬件老化导致。

2.3、进程资源占用
2.3.1监控进程 CPU
[root@localhost ~]# pidstat -u 1 1

%usr 进程在用户空间占用的 CPU 百分比
%system 进程在内核空间占用的 CPU 百分比
%guest 进程在虚拟机（Guest）中占用的 CPU 百分比（如 Docker 容器）
%CPU 总 CPU 占用率（%usr + %system + %guest）
2.3.2监控进程内存
[root@STANDALONE ~]# pidstat -r 1 1

RSS 进程占用的物理内存（Resident Set Size，单位：KB）
%MEM 进程占用内存占系统总内存的百分比
2.3.3监控进程磁盘I/O
[root@STANDALONE ~]# pidstat -d 1 1

kB_rd/s 进程每秒从磁盘读取的数据量（单位：KB）
kB_wr/s 进程每秒写入磁盘的数据量（单位：KB）
kB_ccwr/s 进程每秒取消的写入数据量（如缓存中被覆盖的未写入数据）
2.3.4 监控指定进程所包含线程
1346进程包含线程按cpu使用率降序取前十条
[root@STANDALONE ~]# pidstat -p 1346 -ut|sort -k 9 -r|head -10
1346进程包含线程按磁盘读取量降序取前三十条
[root@STANDALONE ~]# pidstat -p 1346 -dt|sort -k 5 -r|head -30

三、问题SQL定位排查

不良的SQL语句最明显的问题，就会造成服务器资源使用率的飙升，影响其他正常的业务无法获取资源造成等待，通过对操作系统cpu及内存的查看，来识别系统资源的瓶颈。
3.1通过活动会话识别慢SQL
3.1.1 实时会话执行时间
     通过执行以下SQL可以快速定位正在运行的SQL语句，找到run_time数值大，且出现频率高的SQL就是需要重点进行处理的。
select SESS_ID, state,thrd_id,dbms_lob.substr(sf_get_session_sql(sess_id)) sql_text,datediff(ss, last_send_time, sysdate) run_time
from vsessions where state<>'IDLE' and sess_id != sessid order by 5 desc; 3.1.2.查看数据库最慢的sql select * from VLONG_EXEC_SQLS order by exec_time desc;

3.2内存使用情况分析
查询占用内存高的SQL语句
select SESSID,SQL_TXT,LOGIC_READ_CNT,PHY_READ_CNT,MAX_MEM_USED/1024 MEM_USED_MB from V$SQL_STAT order by MAX_MEM_USED desc ;

3.3事务等待检查
 SQL执行缓慢，也有可能是业务逻辑设计不合理导致的事务阻塞，应检查是否存在事务等待信息。提供执行以下SQL可以查询是否存在锁等待的情况。
select tw.id as “等待的事务ID”, tw.wait_for_id as “正在运行的事务ID”, s.sess_id as “等待的会话”, ws.sess_id as “正在执行的会话”, s.sql_text as “等待的sql”, ws.sql_text as “正在执行的sql” , ‘SP_CLOSE_SESSION(’||ws.sess_id||’);’ “关闭会话的语句”, ws.thrd_id “会话线程”
from v$trxwait tw left join v$sessions s
on tw.id=s.trx_id
left join v$sessions ws
on tw.wait_for_id=ws.trx_id;