スキャンの種類（Seq / Index / Index Only / Bitmap）

4 つの表記

テーブルからデータを取り出すノードには 4 つの顔があります。どれが出ているかで、何をしているかが分かります。

先に用語を 1 つ。この先に出てくる Heap（Bitmap Heap Scan /Heap Blocks / Heap Fetches）はテーブル本体のことです。インデックスと区別するための呼び名で、「Heap を読んだ」＝「テーブル本体を読んだ」と読み替えて構いません。

Seq Scan — 先頭から最後まで読む

 Seq Scan on members  (cost=0.00..10417.00 rows=500000 width=34) (actual time=0.006..22.839 rows=500000.00 loops=1)
   Filter: (age >= 20)
   Rows Removed by Filter: 0
 Planning Time: 0.145 ms
 Execution Time: 33.422 ms

テーブルを順番に全部読みます。インデックスが使えないとき、あるいは使わない方が速いと判断されたときに選ばれます。

Index Scan — インデックスを辿って 1 行ずつ取りに行く

 Index Scan using members_pkey on members  (cost=0.42..8.44 rows=1 width=34) (actual time=0.015..0.016 rows=1.00 loops=1)
   Index Cond: (id = 42)
   Index Searches: 1
 Planning Time: 0.253 ms
 Execution Time: 0.046 ms

Index Cond: に条件が乗っているのが目印です。 インデックスで場所を特定してから、その行があるページを読みに行きます。

該当行が多いと不利になります。行ごとにページをバラバラに読むことになるためです。

Index Only Scan — テーブルを読まない

SELECT city FROM members WHERE city = 'city-7';

取り出すのが city だけで、 その city にインデックスが張ってあります。欲しい値がインデックスの中に全部あるので、テーブル本体に用がありません。

 Index Only Scan using members_city_idx on members  (cost=0.42..213.17 rows=10100 width=7) (actual time=0.032..0.435 rows=10000.00 loops=1)
   Index Cond: (city = 'city-7'::text)
   Heap Fetches: 0
   Index Searches: 1
 Planning Time: 0.278 ms
 Execution Time: 0.689 ms

必要な列が全部インデックスに入っているときだけ選ばれます。 テーブル本体を読まないので、いちばん速い形です。Heap Fetches: 0 が「1 回も触っていない」印です。

これを狙って作るのがカバリングインデックスです。遅いノードの見つけ方では、 実際にこれで内側を 5 分の 1 にしています。

Bitmap Heap Scan — 位置を集めてから、まとめて読む

 Bitmap Heap Scan on members  (cost=114.70..4407.95 rows=10100 width=34) (actual time=0.815..5.297 rows=10000.00 loops=1)
   Recheck Cond: (city = 'city-7'::text)
   Heap Blocks: exact=4167
   ->  Bitmap Index Scan on members_city_idx  (cost=0.00..112.17 rows=10100 width=0) (actual time=0.507..0.507 rows=10000.00 loops=1)
         Index Cond: (city = 'city-7'::text)
         Index Searches: 1
 Planning Time: 0.209 ms
 Execution Time: 5.571 ms

2 段構えになっているのが特徴です。

1. Bitmap Index Scan がインデックスを辿って、該当行の位置だけを集める
2. Bitmap Heap Scan が、集めた位置をページ順に並べ替えて読む

Index Scan がインデックスを引くたびにテーブルへ飛ぶのに対して、先に位置を全部集めてから、ページ順にまとめて読むのが違いです。 該当行が「そこそこ多い」ときに選ばれます。

ここで Heap Blocks: exact=4167 の意味を確かめてください。これは実際に読んだページ数です。この例が返しているのは 50 万行のうち 1 万行（2%）だけなのに、読んだページ数は 4,167 ページ —— 上の Seq Scan がテーブル全体を読んだのと同じ数です。

Recheck Cond: が出るのは、 ビットマップが粗くなったときにページ単位で持つことがあり、 そのとき行を読んでから条件をもう一度確かめるためです。 この行の読み方はIndex Cond と Filter の違いに。

何 % を超えると全表スキャンになるか

実際に測りました。50 万行のテーブルで、条件に合う行の割合を少しずつ上げていきます。

50% 前後で切り替わりました。250,550 行（50.1%）までは Bitmap Heap Scan、267,083 行（53.4%）から Seq Scan です。

つまり「インデックスがあるのに Seq Scan になっている」のは、 たいてい正しい判断です。半分読むなら順に読んだ方が速いからです。

インデックスがあるのに使われないとき

ここまでは「対象行が多いから使わない」という正しいケースでした。 それ以外の理由で使われないことも多くあります。 列に関数をかけた、型が合っていない、複合インデックスの左端を使っていない、など。

そちらはインデックスが使われないときに何を見るかに まとまっています。