OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:) その３

---

前回までのMac De Oracle


OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)　その２

---

ということで、続きで〜〜すっ。

こんな表定義で

orcl@SCOTT> desc tab01
 Name      Null?    Type
 --------- -------- --------
 FOO                NUMBER
 BAR                NUMBER
 HOGE      NOT NULL CHAR(2)
 ID        NOT NULL NUMBER

こんな索引があって

****** Index column info : tab01 ******

INDEX_NAME                     COLUMN_NAME                    DESC
------------------------------ ------------------------------ ----
IX1_TAB01                      FOO                            ASC

IX2_TAB01                      BAR                            ASC
                               FOO                            ASC

IX3_TAB01                      ID                             ASC
                               FOO                            ASC

IX4_TAB01                      ID                             ASC
                               BAR                            ASC
                               FOO                            ASC

PK_TAB01                       ID                             ASC

こんなデータで

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
         1 [NULL]     **          2
[NULL]              1 **          3
         1          1 **          4

2列の複合索引、どちらの列もNULLだと、やはり、NULLは索引に含まれないので　IS NULL検索だと索引は利用されないですよねぇ〜。このような状態ではヒントで索引利用を強制利用させようとしても無理です。

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      index(tab01 ix2_tab01)
  5      no_index(tab01 ix4_tab01)
  6      no_index(tab01 ix3_tab01)
  7    */
  8    *
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is null
　　　　　
       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      1 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      1 |      1 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

でも、NOT NUL制約の列が1列でも含まれている索引であればNULLは索引に含まれます。（前回までの復習も兼ねた確認）
第1列がWHERE句で記述されていないので索引スキップスキャンになっていますが.....IS NULL検索を索引アクセスだけで行っているのがよく分かる例の一つです：）

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4    */
  5    *
  6  from
  7    tab01
  8  where
  9    foo is null
 10*   and bar is null

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      1 |00:00:00.01 |       3 |      1 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      1 |      1 |00:00:00.01 |       3 |      1 |
|*  2 |   INDEX SKIP SCAN                   | IX4_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |      1 |
--------------------------------------------------------------------------------------------------------------------

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

   2 - access("BAR" IS NULL AND "FOO" IS NULL)
       filter(("FOO" IS NULL AND "BAR" IS NULL))

最後にもう少しわかりやすい例を。

SQL文を少々書き換えてIndex Only Scanになるようにしました。索引にNULLが含まれていないと索引だけのアクセスで済むわけがないわけで、これ以上わかりやすい例はないと思います：）

まず、索引が利用できない例から。
FOO列とBAR列だけの複合索引をヒントで強制利用させようとしていますが、この索引は２列ともnullableなので２列をIS NULL検索しても索引が利用されません！
全ての列がNULLである場合、キーエントリーは索引に作成されない。単一列でも複合索引でも同じであることが確認できます。

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      index(tab01 ix2_tab01)
  5      no_index(tab01 ix4_tab01)
  6      no_index(tab01 ix3_tab01)
  7    */
  8    *
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is null

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      1 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      1 |      1 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

おっと、
大切なのを忘れてました。

FOO列(nullable(、BAR列(nullable)の複合索引を　IS NOT NULL AND IS NULLで検索した場合はどうなるか？
答えは以下の通り。IS NULL と　IS NOT NULLの組み合わせでも、索引が利用されます。:)

BAR IS NULLで範囲検索しFOO IS NOT NULLでフィルタリングしています。 NULLが含まれていないと不可能な索引レンジスキャンと索引読み時のフィルタリング！

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is not null
 13*   and bar is null

       FOO        BAR
---------- ----------
         1 [NULL]

・・・略・・・
-------------------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.02 |       1 |      1 |
|*  1 |  INDEX RANGE SCAN| IX2_TAB01 |      1 |      1 |      1 |00:00:00.02 |       1 |      1 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("BAR" IS NULL)
       filter("FOO" IS NOT NULL)

その逆も！

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is not null

       FOO        BAR
---------- ----------
[NULL]              1

・・・略・・・
----------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.01 |       2 |
|*  1 |  INDEX SKIP SCAN | IX2_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
----------------------------------------------------------------------------------------

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

   1 - access("FOO" IS NULL)
       filter(("FOO" IS NULL AND "BAR" IS NOT NULL))

もういっちょ！
２列とものnullableな索引だとindex fast full scanにはできないけど、index full scanにはできるんですよ〜。

orcl@SCOTT7gt; r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is not null
 13*   and bar is not null

       FOO        BAR
---------- ----------
         1          1

・・・略・・・
----------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.01 |       2 |
|*  1 |  INDEX FULL SCAN | IX2_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
----------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

Note
-----
   - statistics feedback used for this statement

後に、NOT NULL列が含まれる索引なら index fast full scanでもできるはず！
独り言；index only scan+index fast full scanなんてのもセグメントサイズが小さければ物理読み込み量削減には効果があるんですよねぇ〜　;-)

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      index_ffs(tab01 ix4_tab01)
  6      no_index(tab01 ix2_tab01)
  7    */
  8    foo
  9    , bar
 10  from
 11    tab01
 12  where
 13    foo is not null
 14*   and bar is not null

       FOO        BAR
---------- ----------
         1          1

・・・略・・・
-----------------------------------------------------------------------------------------------------
| Id  | Operation            | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |      1 |        |      1 |00:00:00.03 |       4 |      1 |
|*  1 |  INDEX FAST FULL SCAN| IX4_TAB01 |      1 |      1 |      1 |00:00:00.03 |       4 |      1 |
-----------------------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

オラクルの索引にNULLは絶対含まれない、というのは都市伝説！　
IS NOT NULLは索引使えないとかIS NULLは索引使えないというというのも違うんですよね。　

OracleのB*Tree索引では、索引に含まれる全列がNULLの場合以外はNULLが含まれてまっす！　というのが正しいですよね！？

この手の問題でピンチになったら、思い出してみてください ;)
USE THE INDEX ONLY SCAN, LUKE! w

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:) その２

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)
の続きです。

念のために、もう一つの主役NULL登場してもらいましょう。

IX1_TAB01索引はNullableなFOO列だけの索引なので、このタイプの索引ではNULLは索引に格納されることはありません。
いくらヒントで索引を指定しても索引にはNULLは格納されていないので全表走査になるはず。

注）：索引が多いので意図した索引を利用するようにヒントで固定しています
例２）FOO IS NULL　で検索

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  		no_index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12* 	foo IS NULL


       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
[NULL]              1 **          3


ーーー中略ーーー
Plan hash value: 2044041692

-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      2 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      2 |      2 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter("FOO" IS NULL)

想定通り。NULLは格納されていないので索引が利用できず全表走査になっています。
索引からROWIDを取得できないので全表走査してフィルタリングしている箇所がポイントです。

OracleのB*Tree索引にはNULLが入らない都市伝説の始まりはここだったんじゃないか？　とい言っている方がいたのですが、ここだけの話が広まってしまい

OracleのB*Tree索引にはNULLは絶対格納されない。

という都市伝説になってしまったのだろうと。。確かに入ってないですからねー。 (^^;;;

では、NULLが索引に含まれる一例を見てみましょう。

例３）ID列（NOT NULL)とFOO列（Nullable）で作成した複合索引を ID=1 AND FOO IS NULLで検索
注）：索引が多いので意図した索引を利用するようにヒントで固定しています

Predicate Informationセクションのaccess predicateを見るとわかると思いますが、ID=1 AND FOO IS NULLで索引をアクセスしています。
NULLが索引に含まれていない場合はこのような状況にはなりません。　
複合索引では1列でもNOT NULL制約がり他の列がNullableである場合、NULLは格納されます。

NULLは格納されることもあるんです。マニュアル上の表現は少々わかりにくいとは思いますが、このような状況を指しています。

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		no_index(tab01 ix1_tab01)
  5  		index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12  	id = 1
 13* 	AND foo IS NULL

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

ーーー中略ーーー
Plan hash value: 2558346564

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX RANGE SCAN                  | IX3_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - access("ID"=1 AND "FOO" IS NULL)

少し寄り道。

そういえば、偶になんですが、IS NOT NULLだと索引使うことはないという都市伝説も聞いたことがあります。
それも都市伝説なんですよね。
次の例は、その都市伝説を覆す一例を。

例４）FOO IS NOT NULL　で検索

IX1_TAB01索引は、NullableなFOO列だけの索引です。これまでの検証でこのタイプの索引にはNULLが格納されていないことは確認できると思います。
ようするに、NULLじゃないものは、まるっととズバッと索引に含まれているはずでっす！
なので、FOO IS NOT NULLという検索条件だと索引を使ってくれます。

このような性質を知っているとチューニングに役立つんですよ。
（この例のようなチューニング方法を使ったことは過去数度あるんですよ、苦肉の策でしたけどw　NULLの数が非常に多い場合、この手の索引のセグメントサイズは非常に小さくなります(索引に格納されるエントリそのものがNULLを除くと非常に少ない場合）。その性質を利用したチューニング法もあるんです。）

余談NOTE:
INDEX FAST FULL SCANにならない理由:索引にNOT NULL制約の列が少なくとも１列あること、という前提条件を満たせていないからです。チューニングや設計時に必要な知識なので覚えておくと何かの時に役に立つと思います：）

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  		no_index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12* 	foo IS NOT NULL


       FOO        BAR HO         ID
---------- ---------- -- ----------
         1 [NULL]     **          2
         1          1 **          4

ーーー中略ーーー
Plan hash value: 2840602802

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      2 |00:00:00.01 |       4 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      2 |      2 |00:00:00.01 |       4 |
|*  2 |   INDEX FULL SCAN                   | IX1_TAB01 |      1 |      2 |      2 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - filter("FOO" IS NOT NULL)

恐竜博とか＊＊博ってやつは、最後のショップがメインで博のほうはおまけなんじゃないかと最近思ってるw　子供達の目が活き活きしているのはショップに入ってからだ！w

次回へつづく。

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

先日、OracleのB*Tree索引には絶対にNULLが含まれないって思い込んでる人が意外にいるよね〜とか。
OracleのB*Tree索引には絶対NULLが含まれないって都市伝説があるのはなんでだろう。
Oracle® Database概要12cリリース1 (12.1) - 一意索引と非一意索引

みたいなことが話題になって、
ある一人が、「だよね〜、ダンプ見れば含まれてるのわかります。」って言ってて、それ、ふつ〜の人は見ないからw

と思いつつ、私の周りには、やはり、変態が多いことに改めて気づいた次第です。：）　はい。

で、
変態じゃない、ごく一般的なエンジニアの方々（ブロックダンプを華麗かつ自然にキメちゃわない方々）向けに、

OracleのB*Tree索引にNULLが含まれているか、NULLが含まれていないかの簡単な確認方法をお伝えしなければ！w

ということで、数回にわけて書いておこうかと思ってます。（予定は未定w）

（実は、このネタとほぼ同じことを１年前ぐらい前に、ローカルかつクローズドな勉強会？、でも使ってました。　最近、やってないみたいですけど）

環境は最近の定番　Oracle Database 12c R1 EE

orcl@SCOTT> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
CORE	12.1.0.2.0	Production
TNS for Linux: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production

SCOTTスキーマに以下のような表と索引を作成し少ないですが、データを登録
今回の主役は索引とNULLなのでデータ量少なくても必要なパターンが登録できていれば十分です。
（データ量を増やせばチューニングのお題の元ネタにもなると思います。）

orcl@SCOTT> create table tab01 (foo number, bar number, hoge char(2) not null,id number not null);

Table created.

orcl@SCOTT> insert into tab01 values(null,null,'**',1);

1 row created.

orcl@SCOTT> insert into tab01 values(1,null,'**',2);

1 row created.

orcl@SCOTT> insert into tab01 values(null,1,'**',3);

1 row created.

orcl@SCOTT> insert into tab01 values(1,1,'**',4);

1 row created.

orcl@SCOTT> commit;

Commit complete.

orcl@SCOTT> alter table tab01 add constraint pk_tab01 primary key(id) using index;

Table altered.

orcl@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB01',cascade=>true,no_invalidate=>false);

PL/SQL procedure successfully completed.

orcl@SCOTT> create index ix1_tab01 on tab01 (foo);

Index created.

orcl@SCOTT> create index ix2_tab01 on tab01 (bar,foo);

Index created.

orcl@SCOTT> create index ix3_tab01 on tab01(id,foo);

Index created.

orcl@SCOTT> create index ix4_tab01 on tab01(id,bar,foo);

Index created.

FOOとBAR列はNullableにしています

orcl@SCOTT> desc tab01
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 FOO                                                NUMBER
 BAR                                                NUMBER
 HOGE                                      NOT NULL CHAR(2)
 ID                                        NOT NULL NUMBER

主演の索引たち

NULLが索引でどう扱われるかを確認するため、事前作成の索引をたくさん用意してしました。後から作るの面倒なのでw
これだけ類似索引も含めて多数の索引があると確認時に意図した索引が利用されない可能性も高いため、検証では内容に合わせて利用する索引をヒントで指定することにします。

ちなみに、
普通の環境でこんなに索引があったら、アンチパターン：インデックスショットガンですからね。ご注意ください:) たまにこのような環境に遭遇することはありますが。。。

IX1_TAB01はnullableなFOO列だけの単一列索引
IX2_TAB01はnullableなBAR列とFOO列からなる複合索引
IX3_TAB01とTX4_TAB01は上記の列に加え主キー列のID列を第1キーとする複合索引

としてあります。

orcl@SCOTT> break on table_name on index_name skip 1
orcl@SCOTT> select table_name,index_name,column_name from user_ind_columns where table_name='TAB01' order by table_name,index_name,column_position;

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
TAB01                          IX1_TAB01                      FOO

                               IX2_TAB01                      BAR
                                                              FOO

                               IX3_TAB01                      ID
                                                              FOO

                               IX4_TAB01                      ID
                                                              BAR
                                                              FOO

                               PK_TAB01                       ID

登録したデータは以下の通り
NULLは索引とともに今回の主役なので、どこがNULLになっているかメモしておいてくださいませ。

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01 order by id;

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
         1 [NULL]     **          2
[NULL]              1 **          3
         1          1 **          4

さて、索引にNULLが含まれているか、いないか、どうやって確認すると思います？　ブロックダンプを華麗にキメきめる以外の方法でw

SQLチューニングをしたことがある方なら一般的に利用してい（と思ってる）機能で簡単に確認できちゃうんですよ。これが。

SQL*Plusのautotraceや、explain plan それに、DBMS_XPLAN.DISPLAY*　なファンクションでも確認できます。
SQLclはautotraceにはまだ未対応となっているようですが、それ以外の方法ならはできるようです。
（今回はSQL*Plusを使い、dbms_xplan.display_cursor(format=>'ALLSTATS LAST'))で確認します）

どうやって、どの部分で確認するのか？　
autottraceやDBMS_XPLAN.DISPLAY*などでリストされるpredicate information部分のaccess/filter predicate部分で確認できるんです！

例１）FOO = 1　で検索した例

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

おわかりでしょうか？
Predicate Infomation部分から、Id=2のINDEX RANGE SCANで　IX1_TAB01索引を　FOO=1でアクセスしていることが読み取れますよね？
つまり、1 という値が索引に含まれている（含まれる）からaccess pathとしてIX1_TAB01索引を参照しているわけです。

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  	*/
  6  	*
  7  FROM
  8  	tab01
  9  WHERE
 10* 	foo = 1

       FOO        BAR HO         ID
---------- ---------- -- ----------
         1 [NULL]     **          2
         1          1 **          4

orcl@SCOTT> select * from table(dbms_xplan.display_cursor(format=>'ALLSTATS LAST'));

ーーー中略ーーー

Plan hash value: 3795960549

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      2 |00:00:00.01 |       4 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      2 |      2 |00:00:00.01 |       4 |
|*  2 |   INDEX RANGE SCAN                  | IX1_TAB01 |      1 |      2 |      2 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - access("FOO"=1)

ということで、今日は馬事公苑の散歩は気持ちいいよ〜。

次回へつづく。