posts - 15,comments - 0,views - 22004

  性能问题的定位

  原则尽可能小范围分析问题,如果能够抓到有效信息,就不要把范围扩大,扩大只能让思路更混乱。

  当没有思路的时候先从会话层定位,不要着急先从系统层定位。

  • Sql:如果能定位到sql就不要从会话层面分析 

   工具 执行计划,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

  • 优化器机制开发者无法掌握

  

 

 

 

 

 

 

 

该文章内容来自我学习过程中老师的课件以及工作中的个人经验,如果有不足的地方希望大家指正

posted on   我有我的信仰  阅读(325)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· [翻译] 为什么 Tracebit 用 C# 开发
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· 2分钟学会 DeepSeek API,竟然比官方更好用!
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· 刚刚!百度搜索“换脑”引爆AI圈,正式接入DeepSeek R1满血版
< 2025年2月 >
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 1
2 3 4 5 6 7 8

点击右上角即可分享
微信分享提示