如何进行null与index的分析

这期内容当中小编将会给大家带来有关如何进行空与指数的分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

今天在测试过程中遇到一问题，SQL该走索引的，没走。加索引提示也不行。描述如下：

1.建立测试表

创建表T1级（一种通讯线路的名称）

如同

从dba _对象中选择对象id、对象名称

2.在对象名列上建立b树索引

在t1(对象名)上创建索引idx _ t1 _ name

3.如果我是从T1级（一种通讯线路的名称）中选择对象名，按理说通道总线输出(通道总线输出)应该会选择走索引扫描。但奇怪的是结果走的全表扫描。

结构化查询语言设置自动跟踪跟踪经历

从T1级（一种通讯线路的名称）中选择对象名；

执行计划

–

计划哈希值： 3617692013

–

| Id |操作|名称|行|字节|成本(%CPU)|时间|

–

| 0 | SELECT语句| | 50934 | 3282K | 57(2)| 00:00:01 |

| 1 | TABLE ACCESS FULL | T1 | 50934 | 3282k | 57(2)| 00:00:01 |

–

注意

–

-用于此语句的动态采样

[@more@]

3.使用索引提示想强行走索引，结果还是全表扫描。我就奇怪了。暗示咋个不起做用呢？郁闷。

SQL select /*索引(t1，idx_t1_name) */object_name来自t1；

执行计划

–

计划哈希值： 3617692013

–

| Id |操作|名称|行|字节|成本(%CPU)|时间|

–

| 0 | SELECT语句| | 50934 | 3282K | 57(2)| 00:00:01 |

| 1 | TABLE ACCESS FULL | T1 | 50934 | 3282k | 57(2)| 00:00:01 |

–

注意

–

-用于此语句的动态采样

4.偶然看了下表结构

SQL desc t1

名称为空？类型

– – –

对象标识号

对象名VARCHAR2(128)

空列引起我的注意。对象名可以为null！而在神谕中单个列上建b树索引，空是不会存进索引的（

复合索引可以, 只要整个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-MAR-18

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-MAR-18

再来看看执行结果有没有变化:
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 | 
——————————————————————————–

对于定义为NULL的列，创建位图索引可走索引

上述就是小编为大家分享的如何进行null与index的分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。