【测试】模拟一个全表扫描的sql，对其进行优化走索引，并且将执行计划稳定到baseLine。

①创建表t3：

SQL> create table t3 (id int);

Table created.

SQL> insert into t3 select level from dual connect by level<=100000;

100000 rows created.

②开启自动捕获并修改时间格式：

SQL> alter system set optimizer_capture_sql_plan_baselines=true; 

System altered.

SQL> alter session set nls_date_format=‘yyyy-mm-dd hh24:mi:ss‘;

Session altered.

③查询sql

SQL> select count(*) from t1 where id=1;

  COUNT(*)
----------
         2

SQL> select count(*) from t1 where id=1;

  COUNT(*)
----------
         2

SQL> select sql_handle,sql_text,plan_name,origin,version,created,last_modified,last_executed,last_verified,enabled,accepted,fixed from dba_sql_plan_baselines where sql_text like ‘%select count(*) from t1 where id=1%‘;

SQL_HANDLE
------------------------------
SQL_TEXT
------------------------------------------------------------------------------
PLAN_NAME                      ORIGIN
------------------------------ --------------
VERSION
----------------------------------------------------------------
CREATED
---------------------------------------------------------------------------
LAST_MODIFIED
---------------------------------------------------------------------------
LAST_EXECUTED
---------------------------------------------------------------------------
LAST_VERIFIED
---------------------------------------------------------------------------
ENA ACC FIX
--- --- ---
SQL_c0dca3d9bf76dcbd
select count(*) from t1 where id=1
SQL_PLAN_c1r53v6zrdr5x616acf47 AUTO-CAPTURE
11.2.0.4.0
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM

YES YES NO

④创建索引：

SQL> create index idx_t1 on t1(id);

Index created.

⑤再次执行相同的sql语句：

SQL> select count(*) from t1 where id=1;

  COUNT(*)
----------
         2

SQL> select sql_handle,sql_text,plan_name,origin,version,created,last_modified,last_executed,last_verified,enabled,accepted,fixed from dba_sql_plan_baselines where sql_text like ‘%select count(*) from t1 where id=1%‘;

SQL_HANDLE
------------------------------
SQL_TEXT
------------------------------------------------------------------------------
PLAN_NAME                      ORIGIN
------------------------------ --------------
VERSION
----------------------------------------------------------------
CREATED
---------------------------------------------------------------------------
LAST_MODIFIED
---------------------------------------------------------------------------
LAST_EXECUTED
---------------------------------------------------------------------------
LAST_VERIFIED
---------------------------------------------------------------------------
ENA ACC FIX
--- --- ---
SQL_c0dca3d9bf76dcbd
select count(*) from t1 where id=1
SQL_PLAN_c1r53v6zrdr5x616acf47 AUTO-CAPTURE
11.2.0.4.0
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM

YES YES NO
SQL_c0dca3d9bf76dcbd
select count(*) from t1 where id=1
SQL_PLAN_c1r53v6zrdr5xa9a6a0a8 AUTO-CAPTURE
11.2.0.4.0
17-OCT-16 02.59.07.000000 PM
17-OCT-16 02.59.07.000000 PM

YES NO  NO

⑥演进执行计划：

SQL> SET SERVEROUTPUT ON
SQL> SET LONG 10000
SQL> declare
  2  report clob;
  3  begin
  4  report :=DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(
  5  sql_handle => ‘SQL_c0dca3d9bf76dcbd‘);
  6  DBMS_OUTPUT.PUT_LINE(report);
  7   END;
  8  /

-----------------------------------------------------------------------------
--
                        Evolve SQL Plan Baseline
Report
-----------------------------------------------------------------------
--------

Inputs:
-------
  SQL_HANDLE = SQL_c0dca3d9bf76dcbd
  PLAN_NAME  =

TIME_LIMIT = DBMS_SPM.AUTO_LIMIT
  VERIFY     = YES
  COMMIT     = YES

Plan:
SQL_PLAN_c1r53v6zrdr5xa9a6a0a8
------------------------------------
  Plan was
verified: Time used .09 seconds.
  Plan passed performance criterion: 153.86
times better than baseline plan.
  Plan was changed to an accepted plan.

Baseline Plan      Test Plan       Stats Ratio

-------------      ---------       -----------
  Execution Status:
COMPLETE       COMPLETE
  Rows Processed:                       1
1
  Elapsed Time(ms):                 4.149           .046              90.2

CPU Time(ms):                     4.221           .111             38.03

Buffer Gets:                        309              2             154.5

Physical Read Requests:               0              0
  Physical Write
Requests:              0              0
  Physical Read Bytes:
0              0
  Physical Write Bytes:                 0              0

Executions:                           1
1

---------------------------------------------------------------------------
----
                                 Report
Summary
----------------------------------------------------------------------
---------
Number of plans verified: 1
Number of plans accepted: 1

PL/SQL procedure successfully completed.

⑦再次查看：

SQL> select sql_handle,sql_text,plan_name,origin,version,created,last_modified,last_executed,last_verified,enabled,accepted,fixed from dba_sql_plan_baselines where sql_text like ‘%select count(*) from t1 where id=1‘;

SQL_HANDLE
------------------------------
SQL_TEXT
------------------------------------------------------------------------------
PLAN_NAME                      ORIGIN
------------------------------ --------------
VERSION
----------------------------------------------------------------
CREATED
---------------------------------------------------------------------------
LAST_MODIFIED
---------------------------------------------------------------------------
LAST_EXECUTED
---------------------------------------------------------------------------
LAST_VERIFIED
---------------------------------------------------------------------------
ENA ACC FIX
--- --- ---
SQL_c0dca3d9bf76dcbd
select count(*) from t1 where id=1
SQL_PLAN_c1r53v6zrdr5x616acf47 AUTO-CAPTURE
11.2.0.4.0
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM
17-OCT-16 02.56.20.000000 PM

YES YES NO
SQL_c0dca3d9bf76dcbd
select count(*) from t1 where id=1
SQL_PLAN_c1r53v6zrdr5xa9a6a0a8 AUTO-CAPTURE
11.2.0.4.0
17-OCT-16 02.59.07.000000 PM
17-OCT-16 03.02.17.000000 PM

17-OCT-16 03.02.17.000000 PM
YES YES NO

⑧查看现在查询所用的执行计划：

SQL> select count(*) from t1 where id=1;

Execution Plan
----------------------------------------------------------
Plan hash value: 1970818898

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |     1 |    13 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |        |     1 |    13 |            |          |
|*  2 |   INDEX RANGE SCAN| IDX_T1 |     2 |    26 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"=1)

Note
-----
   - dynamic sampling used for this statement (level=2)
   - SQL plan baseline "SQL_PLAN_c1r53v6zrdr5xa9a6a0a8" used for this statemen
t

Statistics
----------------------------------------------------------
         29  recursive calls
         15  db block gets
         94  consistent gets
          0  physical reads
       3000  redo size
        526  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

时间： 2024-10-06 07:18:08

【测试】模拟一个全表扫描的sql，对其进行优化走索引，并且将执行计划稳定到baseLine。的相关文章

避免全表扫描的sql优化

对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引: .尝试下面的技巧以避免优化器错选了表扫描: · 使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布. · 对扫描的表使用FORCE INDEX告知MySQL,相对于使用给定的索引表扫描将非常耗时. SELECT * FROM t1, t2 FORCE INDEX (index_for_column) WHERE t1.

数据库全表扫描的SQL种类

1．所查询的表的条件列没有索引: 2．需要返回所有的行: 3．对索引主列有条件限制,但是使用了函数,则Oracle 使用全表扫描,如: where upper(city)='TOKYO'; 这样的语句不会使用索引方法.所以就只能全表扫描. 4．带有 is null 和is not null 及 != 等子句.如: . . . where city is null ; . . . where city is not null; . . . where city != 'TOKYO';

【大数据课堂0008】会引起全表扫描的几种SQL 以及sql优化

查询语句的时候尽量避免全表扫描,使用全扫描,索引扫描!会引起全表扫描的几种SQL如下 1.模糊查询效率很低: 原因:like本身效率就比较低,应该尽量避免查询条件使用like:对于like ‘%...%’(全模糊)这样的条件,是无法使用索引的,全表扫描自然效率很低:另外,由于匹配算法的关系,模糊查询的字段长度越大,模糊查询效率越低. 解决办法:首先尽量避免模糊查询,如果因为业务需要一定要使用模糊查询,则至少保证不要使用全模糊查询,对于右模糊查询,即like ‘…%’,是会使用索引的:左模糊lik

如何导致全表扫描原因

转一位大神的笔记. 导致表的执行计划做全表扫描的原因: u SQL谓词列没有建相应的索引 u 谓词列建有相应的索引,但执行计划没有使用 Oracle不使用b*tree索引的情况大致如下 1:where条件中和null比较可能导致不使用索引 2:count,sum,ave,max,min等聚集操作时可能导致不使用索引 3:显示或者隐式的函数转换导致不使用索引 4:在cbo模式下,统计信息过于陈旧导致不使用索引 5:组合索引中没有使用前导列导致没有使用索引 6:访问的数据量超

造成MySQL全表扫描的原因

全表扫描是数据库搜寻表的每一条记录的过程,直到所有符合给定条件的记录返回为止.通常在数据库中,对无索引的表进行查询一般称为全表扫描:然而有时候我们即便添加了索引,但当我们的SQL语句写的不合理的时候也会造成全表扫描.以下是经常会造成全表扫描的SQL语句及应对措施: 1. 使用null做为判断条件如:select account from member where nickname = null; 建议在设计字段时尽量将字段的默认值设为0,改为select account where nickn

mysql 全表扫描场景

全表扫描是数据库搜寻表的每一条记录的过程,直到所有符合给定条件的记录返回为止.通常在数据库中,对无索引的表进行查询一般称为全表扫描:然而有时候我们即便添加了索引,但当我们的SQL语句写的不合理的时候也会造成全表扫描. 以下是经常会造成全表扫描的SQL语句及应对措施: 1. 使用null做为判断条件如:select account from member where nickname = null; 建议在设计字段时尽量将字段的默认值设为0,改为select account where nick

SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

原文:SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index Seek))呢?是否所有情况都是如此?又该如何优化呢? 下面我们通过一些简单的例子来分析理解这些现象.下面的实验环境为SQL SERVER 2008,如果在不同版本有所区别,欢迎指正. 堆表单索引首先我们构建我们测试需要实验环境,

ORA-03113 SQL中select语句全表扫描带来的异常

今天在ERP系统的维护过程中,业务人员反馈了一个问题过来,是ERP系统生产单模块的预览打印报表出错,看到后我逐步做了以下的排查: 1.尝试其他单据是否存在相同问题 2.直接打开水晶报表,将参数代入看看是否是报表问题排查之后逐渐发现,问题出在数据源身上,找到返回数据集的存储过程,进入测试窗口检查是否运行正常,结果发现运行即进入卡死状态,进程无法中断,只好强行退出PL/SQL,这时候我估计到问题出在SQL语句上,因此将SQL语句复制到新的窗口,代入参数,如下: SELECT WO_NBR,WO_L

SQL 数据优化索引建suo避免全表扫描

首先什么是全表扫描和索引扫描?全表扫描所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果.如果数据没建立索引. 无索引的情况下搜索数据的速度和占用内存就会比用索引的检索慢和高.下面是一个例子 1:无索引的情况 Product表,里面没有任何索引,如下图: 从上图中,我悲剧的看到了,物理读是9次,也就说明走了9次硬盘,你也可以想到,走硬盘的目的是为了拿数据,逻辑读有1636次,要注意的是这里的”次“是“页”的意思,也就是在内存中走了1636个数据页,我用dbcc