性能问题的定位
原则尽可能小范围分析问题,如果能够抓到有效信息,就不要把范围扩大,扩大只能让思路更混乱。
当没有思路的时候先从会话层定位,不要着急先从系统层定位。
工具 执行计划,10053,10046
v$session,v$sesstat,v$session_wait,v$sql,v$lock,sql_trace
awr(8i叫做statspack),os tools(top,iostat)
如果对业务不是十分了解,去看awr可能得到的结果不是十分准确的。比如有可能sql本来就耗费cpu无法再优化,所以单纯看awr中sql耗费cpu不一定就是问题。
不要迷恋优化器
优化器永远无法知道你的业务需求
- 优化器永远无法按照你的业务需求来重写你的sql语句。
- 优化器只能在数学(集合)逻辑上做sql的重写。
高效的sql来自对业务的理解和对sql执行过程的理解
第二种写法明显比第一种耗费小,但优化器自己做不到优化所以还需要对业务了解,自己去写合适的sql
SQL> select * from mytable;
ID VALUE ---------- ---------- 1 10 2 15 3 20
想要得到第三列,第三列是该id前面value值的和
SQL> select t.id,t.value,sum(t1.value) from mytable t,mytable t1 where t.id>=t1.id group by t.id,t.value order by id;
ID VALUE SUM(T1.VALUE) ---------- ---------- ------------- 1 10 10 2 15 25 3 20 45
执行计划
Execution Plan ---------------------------------------------------------- Plan hash value: 1051563216
-------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 52 | 9 (34)| 00:00:01 | | 1 | SORT GROUP BY | | 1 | 52 | 9 (34)| 00:00:01 | | 2 | MERGE JOIN | | 1 | 52 | 8 (25)| 00:00:01 | | 3 | SORT JOIN | | 3 | 78 | 4 (25)| 00:00:01 | | 4 | TABLE ACCESS FULL| MYTABLE | 3 | 78 | 3 (0)| 00:00:01 | |* 5 | SORT JOIN | | 3 | 78 | 4 (25)| 00:00:01 | | 6 | TABLE ACCESS FULL| MYTABLE | 3 | 78 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------
Predicate Information (identified by operation id): ---------------------------------------------------
5 - access(INTERNAL_FUNCTION("T"."ID")>=INTERNAL_FUNCTION("T1"."ID")) filter(INTERNAL_FUNCTION("T"."ID")>=INTERNAL_FUNCTION("T1"."ID"))
Note ----- - dynamic sampling used for this statement (level=2)
Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 14 consistent gets 0 physical reads 0 redo size 742 bytes sent via SQL*Net to client 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 3 rows processed
SQL> Connection closed by foreign host.
===========================================================
SQL> select id,value,sum(value) over (order by id) from mytable;
ID VALUE SUM(VALUE)OVER(ORDERBYID) ---------- ---------- ------------------------- 1 10 10 2 15 25 3 20 45
Execution Plan ---------------------------------------------------------- Plan hash value: 3253109826
------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 3 | 78 | 4 (25)| 00:00:01 | | 1 | WINDOW SORT | | 3 | 78 | 4 (25)| 00:00:01 | | 2 | TABLE ACCESS FULL| MYTABLE | 3 | 78 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------
Note ----- - dynamic sampling used for this statement (level=2)
Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 7 consistent gets 0 physical reads 0 redo size 754 bytes sent via SQL*Net to client 519 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 3 rows processed
SQL>
|
为什么高效的sql这么难?
- sql语言的本质是集合的操作
- 语言的效率是sql语言最难的地方
tablescan 全表扫描
index range scan 索引范围扫描
index fast scan 索引快速扫描
nested loop join 嵌套循环
merge jion
hash join
该文章内容来自我学习过程中老师的课件以及工作中的个人经验,如果有不足的地方希望大家指正
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [翻译] 为什么 Tracebit 用 C# 开发
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· 2分钟学会 DeepSeek API,竟然比官方更好用!
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· 刚刚!百度搜索“换脑”引爆AI圈,正式接入DeepSeek R1满血版