当前位置：首页 > 问答 > 正文

Oracle性能检测那些SQL语句怎么用其实挺关键的，细说给你听

畅苗
问答
2026-01-16 01:37:58
2

说到Oracle数据库的性能检测,光知道有哪些SQL语句是远远不够的，关键是怎么用、在什么情况下用、用完看到数据该怎么想，这就像医生有了听诊器，还得知道听哪里、正常的心跳声是什么样、异常的声音又意味着什么，下面我就细说一下几个核心的SQL语句在实际中该怎么用。

先看整体：系统资源到底被谁吃了？—— V$SQLAREA 视图

你不能一上来就钻牛角尖,得先看看整个数据库有没有“发烧”，这时候，V$SQLAREA 视图是你的望远镜，它记录了所有执行过的SQL语句的汇总信息，关键是怎么用它找问题。

关键字段与用法：
- SQL_TEXT：SQL语句文本（可能被截断，看个大概）。
- EXECUTIONS：执行次数，一条SQL如果执行了几万次，即使单次不快，总消耗也可能很大。
- ELAPSED_TIME：总消耗时间（微秒），这是最直观的“慢”的指标。
- CPU_TIME：总CPU时间（微秒），如果这个值占ELAPSED_TIME的比例很高，说明SQL主要在消耗CPU，可能是计算复杂或索引没用上。
- DISK_READS：物理读次数，如果这个值很高，说明数据没法在内存里找到，要去读硬盘，这是性能杀手。
- BUFFER_GETS：逻辑读次数，也就是访问内存中数据块的次数，即使是在内存，次数太多也说明SQL可能写得不够高效。
实战怎么用：你不能傻傻地SELECT * FROM V$SQLAREA，那会返回海量数据，关键是要排序，把最“可疑”的语句揪出来。

场景1：找最耗时的SQL SELECT SQL_TEXT, EXECUTIONS, ELAPSED_TIME, ELAPSED_TIME/EXECUTIONS AS AVG_TIME FROM V$SQLAREA WHERE EXECUTIONS > 0 ORDER BY ELAPSED_TIME DESC; 这样就能看到从古至今，总耗时最长的SQL是哪几条，如果其中某条SQL执行次数很少但总耗时惊人，说明它单次执行就极慢，需要重点优化。

场景2：找最耗CPU的SQL SELECT SQL_TEXT, EXECUTIONS, CPU_TIME, CPU_TIME/EXECUTIONS AS AVG_CPU_TIME FROM V$SQLAREA WHERE EXECUTIONS > 0 ORDER BY CPU_TIME DESC; 这能帮你找到CPU消耗大户，可能这些语句有复杂的函数计算或者全表扫描。

场景3：找磁盘读最严重的SQL SELECT SQL_TEXT, EXECUTIONS, DISK_READS, DISK_READS/EXECUTIONS AS AVG_READS FROM V$SQLAREA WHERE EXECUTIONS > 0 ORDER BY DISK_READS DESC; 如果平均每次执行都要读很多磁盘，你就得考虑是不是该加索引了，或者SQL写法导致索引失效。

再看细节：这条SQL到底是怎么执行的？—— 执行计划

通过V$SQLAREA找到嫌疑犯后，下一步就是“审问”，看看它内部是怎么工作的，这就是看执行计划，执行计划告诉你Oracle打算如何获取数据，是先走索引，还是全表扫描，有没有排序等昂贵操作。

关键怎么用：最常用的方法是使用DBMS_XPLAN包。
1. 获取这条SQL的SQL_ID，你可以在V$SQLAREA的查询结果里找到它。
2. 用这个SQL_ID来查看其执行计划： SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id')); （这里的&sql_id需要你替换成具体的值）
怎么看懂执行计划（简单说）：执行计划是缩进格式的，要看懂父子关系，缩进越多的步骤越先执行，重点关注：
- 操作类型：看到TABLE ACCESS FULL（全表扫描）就要警惕，尤其是对大表，理想情况应该是INDEX RANGE SCAN（索引范围扫描）。
- 成本（Cost）：Oracle估算的执行成本，数值越大一般越慢，可以用来比较不同执行计划的优劣。
- 访问数据量（Rows）：每一步返回或处理的数据行数，如果某一步处理了巨量数据，这就是瓶颈。
- 额外信息（Predicate Information）：这里会告诉你访问条件，比如access和filter，能看出索引是否被有效利用。

实时监控：现在谁正在捣乱？—— V$SESSION 和 V$SQL

上面两种是“事后分析”，有时候问题正在发生，系统卡顿，你需要立刻找到“元凶”，这时就要联合查询V$SESSION和V$SQL视图。

关键怎么用： SELECT s.sid, s.serial#, s.username, s.program, s.event, q.sql_text FROM v$session s, v$sql q WHERE s.sql_id = q.sql_id AND s.status = 'ACTIVE' AND s.username IS NOT NULL;
这个查询在干什么：
- 它把当前正在活动的会话（v$session）和它正在执行的SQL语句（v$sql）关联起来。
- s.event字段极其重要！它表示会话当前在“等待”什么资源，常见的如：
  - db file sequential read：通常在等待索引块的读取。
  - db file scattered read：通常在等待全表扫描的多块读取。
  - enq: TX - row lock contention：遇到行锁等待，可能就是有人锁住了数据没提交。
- 通过这个查询,你能实时看到是哪个用户、从哪个程序、在执行什么SQL、以及它卡在哪个环节了，这对于解决突发的性能瓶颈至关重要。