Null 对 Index 的阴谋

今天在测试过程中遇到一问题, SQL该走Index的,没走. 加index hint也不行. 描述如下:

1. 建立测试表
create table t1
as
select object_id, object_name from dba_objects;

2. 在object_name列上建立b-tree index
create index idx_t1_name on t1(object_name);

3. 如果我是select object_name from t1, 按理说CBO应该会选择走Index scan. 但奇怪的是结果走的full table scan.
SQL> set autotrace trace exp
SQL> select object_name from t1;

Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50934 | 3282K| 57 (2)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 50934 | 3282K| 57 (2)| 00:00:01 |
--------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

[@more@]

3. 使用index hint想强行走Index, 结果还是full table scan. 我就奇怪了. hint咋个不起做用呢? 郁闷.
SQL> select /*+ index(t1, idx_t1_name) */ object_name from t1;

Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50934 | 3282K| 57 (2)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 50934 | 3282K| 57 (2)| 00:00:01 |
--------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

4. 偶然看了下表结构
SQL> desc t1
Name Null? Type
----------------------------------------- -------- ----------------------------
OBJECT_ID NUMBER
OBJECT_NAME VARCHAR2(128)

NULL列引起我的注意. OBJECT_NAME可以为null !! 而在oracle中单个列上建b-tree Index, null是不会存进Index的( 复合索引可以, 只要整个Index columns不为null ). 那就是说如果有些行的object_name是null, 那走Index取值不是会丢掉object_name为null的行. 那如果我让object_name not null 呢?

SQL> alter table t1 modify object_name not null;

Table altered.

SQL> desc t1
Name Null? Type
----------------------------------------- -------- ----------------------------
OBJECT_ID NUMBER
OBJECT_NAME NOT NULL VARCHAR2(128)

再试一试
SQL> select object_name from t1;

Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50934 | 3282K| 57 (2)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 50934 | 3282K| 57 (2)| 00:00:01 |
--------------------------------------------------------------------------

结果还是full table scan : (

试试用hint
SQL> select /*+ index(t1, idx_t1_name) */ object_name from t1;

Execution Plan
----------------------------------------------------------
Plan hash value: 1352742509

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50934 | 3282K| 264 (1)| 00:00:04 |
| 1 | INDEX FULL SCAN | IDX_T1_NAME | 50934 | 3282K| 264 (1)| 00:00:04 |

这回hint 起作用了. 这说明并不是Hint失效, 只是满足走Index的条件一开始没有具备. 看来null是个潜在杀手, 得小心防范.
现在强走index是ok了. 但, 是什么东西会影响CBO的判断不走Index呢? 想到统计信息可能会是原因之一, 于是查看了一下.

SQL> select index_name, LAST_ANALYZED from user_indexes;
INDEX_NAME LAST_ANALYZED
------------------------------------------------------------------------------------------ ---------------
IDX_T1_NAME 01-DEC-09

SQL> select table_name, LAST_ANALYZED from user_tables;

TABLE_NAME LAST_ANALYZED
------------------------------------------------------------------------------------------ ---------------
T1

看到刚建的表没有做过统计. 于是 go to analyze table, 结果如下:

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

PL/SQL procedure successfully completed.

SQL> select table_name, LAST_ANALYZED from user_tables;

TABLE_NAME LAST_ANALYZED
------------------------------------------------------------------------------------------ ---------------
T1 01-DEC-09

再来看看执行结果有没有变化:
SQL> select object_name from t1;

Execution Plan
----------------------------------------------------------
Plan hash value: 222950081

------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 49917 | 1218K| 57 (2)| 00:00:01 |
| 1 | INDEX FAST FULL SCAN| IDX_T1_NAME | 49917 | 1218K| 57 (2)| 00:00:01 |
------------------------------------------------------------------------------------

这下终于走Index这条路老 : ) 在Index 中, key value是排序存放的. Index Fast full scan 它是按照block的存储顺序来读取数据, 并可以一次I/O多块读取提高效率( 参数 readdb_file_multiblock_read_count), 但返回的值是没有排序的. 而
Index full scan会按照Key value顺序读取值, 返回排了序的结果. 所以, 做个order by会是走Index full scan.

SQL> select object_name from t1 order by object_name;

Execution Plan
----------------------------------------------------------
Plan hash value: 1352742509

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 49917 | 1218K| 249 (1)| 00:00:03 |
| 1 | INDEX FULL SCAN | IDX_T1_NAME | 49917 | 1218K| 249 (1)| 00:00:03 |
--------------------------------------------------------------------------------

果然, 呵呵.

至此, 原因找到, gained experience.

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

转载于:http://blog.itpub.net/7319061/viewspace-1029258/