這期內(nèi)容當中小編將會給大家?guī)碛嘘P如何進行null與index的分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

目前累計服務客戶上1000+，積累了豐富的產(chǎn)品開發(fā)及服務經(jīng)驗。以網(wǎng)站設計水平和技術實力，樹立企業(yè)形象，為客戶提供網(wǎng)站設計、成都做網(wǎng)站、網(wǎng)站策劃、網(wǎng)頁設計、網(wǎng)絡營銷、VI設計、網(wǎng)站改版、漏洞修補等服務。成都創(chuàng)新互聯(lián)公司始終以務實、誠信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過對領先技術的掌握、對創(chuàng)意設計的研究、對客戶形象的視覺傳遞、對應用系統(tǒng)的結(jié)合，為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。

今天在測試過程中遇到一問題, 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. 但奇怪的是結(jié)果走的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, 結(jié)果還是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. 偶然看了下表結(jié)構(gòu)
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 |
--------------------------------------------------------------------------


結(jié)果還是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是個潛在殺手, 得小心防范. 
現(xiàn)在強走index是ok了. 但, 是什么東西會影響CBO的判斷不走Index呢? 想到統(tǒng)計信息可能會是原因之一, 于是查看了一下.


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




看到剛建的表沒有做過統(tǒng)計. 于是 go to analyze table, 結(jié)果如下:


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




再來看看執(zhí)行結(jié)果有沒有變化:
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的存儲順序來讀取數(shù)據(jù), 并可以一次I/O多塊讀取提高效率( 參數(shù) readdb_file_multiblock_read_count), 但返回的值是沒有排序的. 而
Index full scan會按照Key value順序讀取值, 返回排了序的結(jié)果. 所以, 做個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的列，創(chuàng)建位圖索引可走索引

上述就是小編為大家分享的如何進行null與index的分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)頁名稱：如何進行null與index的分析
鏈接分享：http://m.2m8n56k.cn/article14/jcgede.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供標簽優(yōu)化、虛擬主機、移動網(wǎng)站建設、網(wǎng)站建設、、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：[email protected]。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)