统计信息过旧,会误导CBO

首先创建一张测试表

 

SQL> create table t1 as select 1 id,object_name,object_type from sys.dba_objects;

 

Table created.

 

SQL> select count(*) total,count(distinct id) column_id_valnum from t1;

 

     TOTAL COLUMN_ID_VALNUM

---------- ----------------

     50345                1

 

SQL> create index idx_t1_id on t1(id);

 

Index created.

 

一共有5万多条记录,但是id列只有一种值‘1’。

下面,手工对这张表的统计信息进行收集。

SQL> exec dbms_stats.gather_table_stats(user,'T1');

 

PL/SQL procedure successfully completed.

 

现在,我们执行查询,看看它的执行计划是怎样的。

 

SQL> set autotrace trace exp stat

SQL> select * from t1 where id=1;

 

50345 rows selected.

 

 

Execution Plan

----------------------------------------------------------

Plan hash value: 3617692013

 

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 50345 |  1720K|    69   (3)| 00:00:01 |

|*  1 |  TABLE ACCESS FULL| T1   | 50345 |  1720K|    69   (3)| 00:00:01 |

--------------------------------------------------------------------------

 

Predicate Information (identified by operation id):

---------------------------------------------------

 

   1 - filter("ID"=1)

 

 

Statistics

----------------------------------------------------------

          1  recursive calls

          0  db block gets

       3630  consistent gets

          0  physical reads

          0  redo size

    1817080  bytes sent via SQL*Net to client

      37301  bytes received via SQL*Net from client

       3358  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

      50345  rows processed

 

生成的执行计划非常准确。及时在表上创建索引,但是由于id的值都是‘1’,所以CBO还是采取全表扫面的执行计划。

下面我们要修改表,将50340条记录的id改为‘9999’,并且不收集信息情况下,重新执行查询,看看会是什么情况。

SQL> update t1 set id=9999 where rownum<50341;

 

50340 rows updated.

 

SQL> commit;

 

Commit complete.

SQL> select * from t1 where id=1;

 

 

Execution Plan

----------------------------------------------------------

Plan hash value: 3617692013

 

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 50345 |  1720K|    69   (3)| 00:00:01 |

|*  1 |  TABLE ACCESS FULL| T1   | 50345 |  1720K|    69   (3)| 00:00:01 |

--------------------------------------------------------------------------

 

Predicate Information (identified by operation id):

---------------------------------------------------

 

   1 - filter("ID"=1)

 

 

Statistics

----------------------------------------------------------

          0  recursive calls

          0  db block gets

        291  consistent gets

          0  physical reads

          0  redo size

        676  bytes sent via SQL*Net to client

        385  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

          5  rows processed

 

这个执行计划与我们的想法相左,修改完之后,为‘1’的记录应该是5条,使用索引应该比全表扫面要优,但是现在的执行计划确实全表扫描,就是因为统计信息过旧,造成执行计划不准确。

处理这个问题可以手工收集一次统计信息。

 

SQL> exec dbms_stats.gather_table_stats(user,'T1');

 

PL/SQL procedure successfully completed.

 

SQL> select * from t1 where id=1;

 

 

Execution Plan

----------------------------------------------------------

Plan hash value: 190799060

 

--------------------------------------------------------------------------------

---------

 

| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| T

ime     |

 

--------------------------------------------------------------------------------

---------

 

|   0 | SELECT STATEMENT            |           |    18 |   648 |     2   (0)| 0

0:00:01 |

 

|   1 |  TABLE ACCESS BY INDEX ROWID| T1        |    18 |   648 |     2   (0)| 0

0:00:01 |

 

|*  2 |   INDEX RANGE SCAN          | IDX_T1_ID |    18 |       |     1   (0)| 0

0:00:01 |

 

--------------------------------------------------------------------------------

---------

 

 

Predicate Information (identified by operation id):

---------------------------------------------------

 

   2 - access("ID"=1)

 

 

Statistics

----------------------------------------------------------

          0  recursive calls

          0  db block gets

        291  consistent gets

          0  physical reads

          0  redo size

        676  bytes sent via SQL*Net to client

        385  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

          5  rows processed

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26812308/viewspace-746922/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/26812308/viewspace-746922/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值