【SQL 优化】异常的逻辑读

实验环境

SQL> select * from v$version;

BANNER                                                                         
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production         
PL/SQL Release 11.1.0.6.0 - Production                                          
 

SQL> create table t as select * from all_objects where 1=0;
表已创建。
SQL> set timing on;
SQL> insert into t select * from all_objects ;
已创建67670行。
已用时间:  00: 00: 21.00
SQL> commit;
提交完成。
已用时间:  00: 00: 00.00
SQL> insert into t select * from all_objects ;
已创建67670行。
已用时间:  00: 00: 13.53
SQL> commit;
提交完成。
已用时间:  00: 00: 00.00
SQL> insert into t select * from all_objects ;
已创建67670行。
已用时间:  00: 00: 13.68
SQL> commit;
提交完成。
已用时间:  00: 00: 00.00
SQL> begin
  2  dbms_stats.gather_table_stats(user,'T');--信息统计
  3  end;
  4  /
PL/SQL 过程已成功完成。
已用时间:  00: 00: 03.07
SQL> set autotrace on                                  
SQL> set linesize 120
SQL> set autot traceonly stat
SQL> select owner,object_name,object_id, count(*)
  2  from t group by owner ,object_name,object_id;
已选择67670行。
已用时间:  00: 00: 01.76
统计信息
---------------------------------
          0  recursive calls
          0  db block gets 
       2979  consistent gets ----全表扫描时的逻辑读
        792  physical reads
          0  redo size  
    2964477  bytes sent via SQL*Net to client
      50037  bytes received via SQL*Net from client
       4513  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk) 
      67670  rows processed
SQL> create index idx_t on t (owner,object_name,object_id);--建立索引
索引已创建。
已用时间:  00: 00: 01.43
SQL> begin
  2  dbms_stats.gather_table_stats(user,'T',cascade => true);--信息统计
  3  end;
  4  /
PL/SQL 过程已成功完成。
已用时间:  00: 00: 03.46
SQL> set autot traceonly
SQL> select owner,object_name,object_id, count(*)
  2  from t group by owner ,object_name,object_id;
已选择67670行。
已用时间:  00: 00: 01.62
执行计划
---------------------------------------------------------- 
Plan hash value: 3184476542
------------------------------------------------------------------------------
| Id  | Operation            | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |       | 67670 |  2379K|  1310   (1)| 00:00:16 |
|   1 |  SORT GROUP BY NOSORT|       | 67670 |  2379K|  1310   (1)| 00:00:16 | 
|   2 |   INDEX FULL SCAN    | IDX_T |   203K|  7137K|  1310   (1)| 00:00:16 | 
------------------------------------------------------------------------------                                        
统计信息
----------------------------------------------------------                                                             
          0  recursive calls 
          0  db block gets 
       5795  consistent gets---几乎是FTS 的两倍的逻辑读。 
          0  physical reads
          0  redo size   
    2866263  bytes sent via SQL*Net to client 
      50037  bytes received via SQL*Net from client
       4513  SQL*Net roundtrips to/from client  
          0  sorts (memory) 
          0  sorts (disk) 
      67670  rows processed
已用时间:  00: 00: 00.06
做一个10053 事件看看

***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table:  T  Alias:  T
    #Rows: 203010  #Blks:  2973  AvgRowLen:  101.00
Index Stats::
  Index: IDX_T  Col#: 1 2 4
    LVLS: 2  #LB: 1306  #DK: 67670  LB/K: 1.00  DB/K: 3.00  CLUF: 203010.00
Access path analysis for T --路径选择
***************************************
SINGLE TABLE ACCESS PATH
  Single Table Cardinality Estimation for T[T]
  Table: T  Alias: T
    Card: Original: 203010.000000  Rounded: 203010  Computed: 203010.00  Non Adjusted: 203010.00
  Access Path: TableScan
    Cost:  809.88  Resp: 809.88  Degree: 0
      Cost_io: 807.00  Cost_cpu: 63804141
      Resp_io: 807.00  Resp_cpu: 63804141
  Access Path: index (index (FFS))
    Index: IDX_T
    resc_io: 355.00  resc_cpu: 33661801
    ix_sel: 0.000000  ix_sel_with_filters: 1.000000
  Access Path: index (FFS)
    Cost:  356.52  Resp: 356.52  Degree: 1
      Cost_io: 355.00  Cost_cpu: 33661801
      Resp_io: 355.00  Resp_cpu: 33661801
  Access Path: index (FullScan)
    Index: IDX_T
    resc_io: 1308.00  resc_cpu: 49916844
    ix_sel: 1.000000  ix_sel_with_filters: 1.000000
    Cost: 1310.25  Resp: 1310.25  Degree: 1
  Best:: AccessPath: IndexFFS  --最佳路径
  Index: IDX_T
         Cost: 356.52  Degree: 1  Resp: 356.52  Card: 203010.00  Bytes: 0

但是从执行计划的结果上看,走索引却耗费更多的逻辑读!

时间: 2024-11-02 04:38:01

【SQL 优化】异常的逻辑读的相关文章

理解SQL SERVER中的逻辑读,预读和物理读

SQL SERVER数据存储的形式 在谈到几种不同的读取方式之前,首先要理解SQL SERVER数据存储的方式.SQL SERVER存储的最小单位为页(Page).每一页大小为8k,SQL SERVER对于页的读取是原子性,要么读完一页,要么完全不读,不会有中间状态.而页之间的数据组织结构为B树.所以SQL SERVER对于逻辑读,预读,和物理读的单位是页. SQL SERVER一页的总大小为:8K 但是这一页存储的数据会是:8K=8192字节-96字节(页头)-36字节(行偏移)=8060字节

理解SQL SERVER中的逻辑读,预读和物理读_MsSql

SQL SERVER数据存储的形式       在谈到几种不同的读取方式之前,首先要理解SQL SERVER数据存储的方式.SQL SERVER存储的最小单位为页(Page).每一页大小为8k,SQL SERVER对于页的读取是原子性,要么读完一页,要么完全不读,不会有中间状态.而页之间的数据组织结构为B树(请参考我之前的博文).所以SQL SERVER对于逻辑读,预读,和物理读的单位是页.             SQL SERVER一页的总大小为:8K       但是这一页存储的数据会是:

大量逻辑读的瓶颈分析和优化

原创 转载请注明出处 我的工作记录:  昨天早上生产库出现了大约一个小时资源耗尽的情况,分析得出语句如下: MERGE INTO T_DPD_AGENT_CHANGE A USING (SELECT A.AGENT_ID,               A.ENTER_COMPANY_DATE ENTER_DATE,               A.LEAVE_COMPANY_DATE LEAVE_DATE,               A.AGENT_STATUS,              

Oracle查看逻辑读、物理读资源占用排行的SQL语句_oracle

查看逻辑读前10的SQL: 复制代码 代码如下: set linesize 300; set pagesize 300; set long 50000; SELECT * FROM (     SELECT sql_fulltext AS sql, SQL_ID,buffer_gets / executions AS "Gets/Exec",buffer_gets, executions     FROM V$SQLAREA     WHERE buffer_gets > 100

ORACLE SQL调优之统计信息缺失导致的逻辑读暴增

    2016年11月8日,接到广西负责人申告,说决策系统一条SQL平时执行2s左右能执行完,现在却要执行2:30多才能出结果,请求对其做处理.     操作系统:RHEL LINUX 6.4     数据库版本:11.2.0.4     首先,登录服务器查看数据库服务器的状态: [oracle@orcl ~]$ free -m              total       used       free     shared    buffers     cached Mem:    

一次马失前蹄的SQL优化:递归查询引发的血案

作者介绍 黄浩:从业十年,始终专注于SQL.十年一剑,十年磨砺.3年通信行业,写就近3万条SQL:5年制造行业,遨游在ETL的浪潮:2年性能优化,厚积薄发自成一家.   在上个案例分享时,有读者表示"很想知道,作者失败的时候是怎么办?",并且看热闹不嫌事大,要求"来一篇文章呗".好吧,正所谓,常在河边走,哪有不湿鞋.本人在SQL优化领域摸爬滚打多年,"接客"无数,难免会遇到些难以伺候的"官人",本文就跟大家分享一次不成功的优化

SQL优化之六脉神剑

本文作者通过身边的案例,详细阐述了SQL优化过程中的种种方法和小窍门,内容丰富且言之有物,希望能让接触到SQL的同学可以体会到SQL提速的乐趣!   1.前言 关于SQL优化,前辈们.技术大咖们.各个技术论坛上早就有很多的优秀文章,今番我再次提起,心情忐忑,实在是有些班门弄斧和自不量力了. 在大家的鼓励下我想写一下也好,就写我们身边的事,用身边的案例来演绎SQL优化,用形象语言把SQL优化说成我们身边的事,希望能让接触到SQL的同学可以体会到SQL提速的乐趣! 2.理解几个名词 提到SQL优化,

细致入微 | 让 SQL 优化再多飞一会儿

第一章  细致入微 | 让 SQL 优化再多飞一会儿 云和恩墨 | 2016-04-12 20:54 怀晓明 云和恩墨性能优化专家 本文来自于本周四云和恩墨大讲堂怀晓明老师的分享. 内容:作为 DevOps 的最佳落地方式之一的 SQL 审核,如何才能做好?这是一件很有挑战性的事情,他将通过两个具体案例,来展现 SQL 审核工作如何才能做得更好,更有价值.简言之就是八个字--"细致入微,方显价值 ". 我们都知道,细致认真,可以将一件事情做得尽可能完美,在 SQL 审核与优化中,同样需

阿里云慢SQL优化挑战大赛分析

[背景] 阿里云慢SQL优化挑战赛:https://yq.aliyun.com/articles/136363?spm=5176.100240.searchblog.32.oYlhtr [考点分析] 本次慢SQL优化挑战赛的题目全部来自于生产案例,将众多考察点揉合到一条SQL中,主要考虑了以下方面: 表设计:考察字符和数字字段定义,字符集大小写校验,时间字段存储. 驱动表:考察多表join时候最优的连接顺序. 索引优化:考察索引消除排序以,索引隐式转换,覆盖索引避免回表的问题. 执行计划:使用e