【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

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

相关文章
|
3天前
|
SQL 缓存 Java
sql优化方法
sql优化方法
22 0
|
3天前
|
SQL 关系型数据库 MySQL
项目中遇到一张900w的数据表把原先要花费17s执行的SQL优化到300ms经验加100哈哈哈
项目中遇到一张900w的数据表把原先要花费17s执行的SQL优化到300ms经验加100哈哈哈
25 1
|
3天前
|
SQL
启动mysq异常The server quit without updating PID file [FAILED]sql/data/***.pi根本解决方案
启动mysq异常The server quit without updating PID file [FAILED]sql/data/***.pi根本解决方案
31 0
|
3天前
|
SQL 存储 关系型数据库
【MySQL】SQL 优化
【MySQL】SQL 优化
20 0
|
1天前
|
SQL Oracle 关系型数据库
实时计算 Flink版产品使用合集之从MySQL到Flink 1.16.2 Flink-SQL的数据同步工作出现了一个异常如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
13 0
|
3天前
|
SQL 缓存 关系型数据库
一次sql改写优化子查询的案例
在生产环境中,一个MySQL RDS实例遭遇了高CPU使用率问题,原因是执行了一条复杂的UPDATE SQL语句,该语句涉及一个无法缓存的子查询(UNCACHEABLE SUBQUERY),导致子查询需要针对每一行数据重复执行,极大地影响了性能。SQL语句的目标是更新一行数据,但执行时间长达30秒。优化方法是将子查询转换为内连接形式,优化后的语句执行时间降低到毫秒级别,显著减少了CPU消耗。通过示例数据和执行计划对比,展示了优化前后的时间差异和执行效率的提升。
|
3天前
|
存储 SQL 关系型数据库
掌握高性能SQL的34个秘诀🚀多维度优化与全方位指南
掌握高性能SQL的34个秘诀🚀多维度优化与全方位指南
|
3天前
|
SQL 存储 关系型数据库
【MySQL系列笔记】SQL优化
SQL优化是通过调整数据库查询、索引、表结构和配置参数等方式,提高SQL查询性能和效率的过程。它旨在减少查询执行时间、减少系统资源消耗,从而提升数据库系统整体性能。优化方法包括索引优化、查询重写、表分区、适当选择和调整数据库引擎等。
233 3
|
3天前
|
存储 SQL 缓存
30个业务场景的SQL优化
这些优化策略和示例可以帮助改善 `SQL` 查询的性能和效率。在实践中,需要综合考虑数据库设计、`SQL` 编写、服务器配置等多方面因素,选择合适的优化方法,并进行充分的测试和验证。以上 30 个经验是 V 哥在实际经验中总结的内容,当然,业务场景不同,具体的优化策略也会不同,按实际情况处理,这不就是程序员要做的事情么。
|
3天前
|
SQL 存储 算法
clickhouse SQL优化
clickhouse 是 OLAP 数据库,但其具有独特的索引设计,所以如果拿 MySQL 或者其他 RDB 的优化经验来优化 clickhouse 可能得不到很好的效果,所以特此单独整理一篇文档,用于有 SQL 优化需求的同学,本人接触 clickhouse 时间也不长,难免有不足的地方,如果大家发现错误,还请不吝指正。