2019年度、若手技術者向け講座、インデックス講座

1. インデックス

2. 概要
• インデックスの概要や仕組みについて学習します。
• どんなSQLを書いた場合にインデックスが使用されるかを理解
し、速度を意識したSQL文を記述できるようになることを目指
します。
2

3. 目次
• インデックスの概要
• インデックスの仕組み
• インデックスの種類
• インデックスのメリットとデメリット
• インデックスの作成方法
• 演習問題
• インデックスの作成
• インデックスが使用されるSQLはどれか
3

4. 環境
• VM（仮想マシン）の中にPostgreSQL（バージョン11）の環境が構築
されています。
• 環境構築の資料を参考に、「axizdb_index」のDBに接続してください。
• postgresqlにログイン済みの場合
• 未ログインの場合
4
> ¥c axizdb_index
# psql –U axiz –d axizdb_index

5. インデックス
5

6. インデックス
• インデックス（索引）とは
• レコードの検索を高速にする仕組みです。
• 日本語では索引。本の索引と同じ意味です。
• 本の中から目的の用語を探すとき、1ページ目から最後のページまで
順番に探していくのは効率が悪いです。索引を使えば、探したい用語
が載っているページに素早くたどり着くことできます。
• DBでレコードを検索する場合も、インデックスを使用することで、対
象のレコードがどこにあるかを短時間で見つけることができます。
6

7. インデックス
• 辞書の索引を例に考える
• 本の情報（タイトル、著者、出版社、出版日付、概要）が書かれた辞
書がある。
• 100000件の情報が載っており、総ページ数は500ページ。
• 出版日付順に情報が並んでいる。
• 索引がない場合、「SQL入門」というタイトルの本を探すには
何ページ検索する必要があるか。なお、出版日付は分からない
ものとする。
7

8. インデックス
• 「SQL入門」の検索
• 運が良ければ早い段階で見つかるかもしれない。
• しかし、同じタイトルの本が2冊以上ないとも限らない。
• 結局、全ページ（500ページ）を検索する
• タイトルでの索引があれば、索引1～5ページ程度で対象のタイトルを
見つけることができ、トータルでも2～6ページ程度で探していた情報
に辿り着くことができる。
8

9. インデックス
• インデックスを学ぶ必要性
• データベースの世界ではインデックスという言葉がよくでてきます。
• インデックスの仕組みを理解していなくても、SQLを記述することは
できますが、知らず知らずのうちにパフォーマンスの低いSQLを書い
てしまっている可能性があります。
• インデックスの構造や仕組みを理解することで、どんなSQLを書けば
インデックスが適用されるかを理解し、速度を意識したSQLを書くこ
とができるようになります。
9

10. インデックス
• インデックスの仕組み
• テーブルのレコードは、ディスク上でブロック（ページ）という単位
で格納されています。
• ブロックには、そのブロックを特定するためのアドレスが存在します。
• インデックスは、カラムが昇順で並び、カラムの値とアドレスがセッ
トで格納されています。
※B-Treeインデックスの仕組みです。
10

11. インデックス
• インデックスの種類
大きく分けて３つの種類があります。
• B-treeインデックス
• ビットマップインデックス
• ハッシュインデックス
11

12. インデックス
• B-Treeインデックス
• DBMSでインデックスというと大抵の場合はこのB-Treeインデックスの
ことを指します。
• 名前の通り、木構造になっており、検索値からレコードのアドレスを
辿り、実レコードを検索する仕組みです。
12

13. インデックス
• ビットマップインデックス
• 検索値のビットマップを作成し、ビット列から該当レコードを検索す
るインデックスです。
• 値のカーディナリティ（取りうる値の種類）が低いときに効果を発揮
するインデックスです。
• 「性別」「血液型」のような、取る値の種類が決まっていて、かつ、
数が少ないカラムに対してインデックスを作成したい場合には有効な
インデックスです。
• 詳しく知りたい方は以下を参照
https://qiita.com/gohandesuyo/items/b3a684157b2eefc69a79
13

14. インデックス
• ハッシュインデックス
• ハッシュ値を用いたインデックスです。
• 非常に高速な検索が可能ですが、イコールでの検索にしか対応できな
いため、使われる場面は少ないです。
14

15. インデックス
• インデックス作成のメリット
• 検索（SELECT文）が速くなる。
ただし、インデックスが適切に使用されることが前提です。
• 更新（UPDATE文、DELETE文）が速くなる。
UPDATE、DELETEは、一度SELECT文で更新対象のレコードを検索した後
に更新をしています。
そのため、SELECT文が速くなることで、結果的に更新処理が速くなる。
（ただし、更新処理の負荷は増えるため、必ずしも処理が速くなると
は限りません。）
15

16. インデックス
• インデックス作成のデメリット
• インデックスの容量分、ディスクを圧迫する。
• 追加・修正・削除時の負荷が増える。
（インデックス再構築による負荷がかかる）
• 多く作りすぎると検索が遅くなる可能性がある。
（適切なインデックスが使用されない可能性がある）
16

17. インデックス
• インデックス設計
• インデックス作成のメリットとデメリットを知ったうえで、適切なイ
ンデックス設計を作成することが大事です。
• selectの使用頻度、更新の使用頻度などを考慮して適切なインデックス
設計を意識しましょう。
17

18. インデックス
• どのインデックスが使用されるのか
• インデックスは、1つのテーブルに対して複数作成することが可能で
す。
• 検索（SELECT文）を実行するとき、どのインデックスが使用されるの
かはDBMSの判断に委ねられます。
• SQL文にヒント句を記述することで、意図的に使用するインデックス
を指定することもできます。
※ヒント句の指定の仕方、使用可能かどうかはDBMSによって異なりま
す。
18
-- Oracleの場合のヒント句の使用
SELECT /*+ INDEX(テーブル名 インデックス名) */ * FROM table1
WHERE name = 'test'

19. インデックス
• マルチカラムインデックス
• インデックスを作成する場合は、複数のカラムを指定することもでき
ます。
• 複数のカラムの組み合わせで作成したインデックスのことを、マルチ
カラムインデックスといいます。
• 検索の際に、ANDで条件を複数指定する場合は、マルチカラムイン
デックスを作成することでより高速な検索になることが期待できます。
19

20. インデックス
• インデックスの作成方法
• CREATE INDEX 文を使用して作成する
• テーブル作成時にPRIMARY KEY 制約を設けている場合は、
主キーに対してのインデックスは自動で作成される。
20
CREATE INDEX <index_name> ON <table_name> (column1, …)

21. インデックス
• インデックスの作成時の注意点
• システムをリプレイスする際には、データ移行の作業が発生します。
• データ移行を行う際のインデックスの作成には注意が必要です。
• データ移行をする際には、移行前にインデックスを作成すると、デー
タ移行に以上に時間がかかります。
• データ移行の際にはインデックスは移行後に作成する方が良いです。
21

22. まとめ
• インデックスまとめ
• インデックスとは、SQL(SELECT文)を高速化する仕組み。
• インデックスにはいくつかの種類があり、B-Treeインデックス、ビッ
トマップインデックス、ハッシュインデックスなどがある。
• インデックスにはデメリットもあるので、作り過ぎに注意（事前の設
計が大事）。
• SQLの書き方によってインデックスが使用さる場合と使用されない場
合がある。
• データ移行の際はインデックスは移行後に作成する。
22

23. 参考資料
インデックスを先に作る場合と後に作る場合の比較
23

24. 参考資料
• インデックスを先に作る場合と後に作る場合の比較
• 大量のデータを一括でインサートする場合、インデックスを先に作成
するか、後に作成するかによって、実行にかかる時間が大きく変わっ
てきます。
• 以下の資料は、何故時間が変わるかの解説と実際の検証結果を載せま
す。
24

25. 参考資料
• 大量データをインサートする手順
大量のデータを一括でインサートしたい場合
1. テーブル定義作成
2. データのインサート
3. インデックス作成
の手順で実施する方が短時間で処理できます。
間違ってもインデックス作成の手順を先に行ってはいけません！
それはなぜでしょうか。
25

26. 参考資料
• なぜインデックスを後から作成するのか
• インデックスの内部構造は木構造になっている。（B-tree）
• 木の深さは均等になるような構造になっている。
• insert, update, deleteが実行されると、インデックスの構造が
組み変わるアルゴリズムが動く。
データを大量にインサートする場合、インサートのたびにインデック
構造を変化するアルゴリズムが動作するため、DBMS内の負荷が高くな
る。
• インサート後にインデックスを作成すれば木構造を構築するアルゴリ
ズムの実行は一回しか処理されないため、負荷を減らすことができ、
結果的に速度が速くなる。
26

27. 参考資料
• 検証（テーブル定義）
• 実際に検証してみます。以下のような構造のテーブルとインデックス
を用意します。
• 10万件のデータをインサートするとき、インデックスを先に作る場合
と後に作る場合の差異を確認してみます。
27
itest インデックス
物理名 型 primary key 1 id
id int 〇 2 c1
c1 char(500) 3 c2
c2 char(500) 4 c3
c3 char(500) 5 c4
c4 char(500) 6 c5
c5 char(500) 7 c6
c6 char(500) 8 c7
c7 char(500) 9 c8
c8 char(500)

28. 参考資料
• 検証（インデックスを先に作成）
• まずはテーブルを作成します。
28
axizdb=>create table itest(
id int primary key
, c1 char(500)
, c2 char(500)
, c3 char(500)
, c4 char(500)
, c5 char(500)
, c6 char(500)
, c7 char(500)
, c8 char(500)
);

29. 参考資料
• 検証（インデックスを先に作成）
• 次にインデックスを作成します。
• 8つのインデックスを作成します。
29
create index c1_index on itest (c1);
create index c2_index on itest (c2);
create index c3_index on itest (c3);
create index c4_index on itest (c4);
create index c5_index on itest (c5);
create index c6_index on itest (c6);
create index c7_index on itest (c7);
create index c8_index on itest (c8);

30. 参考資料
• 検証（インデックスを先に作成）
• 10万件のデータをインサートするのにかかる時間を検証します。
30
select now(); -- 開始時刻を表示
-- 再帰SQLを使用して、10万件のデータを作成する
insert into itest
with recursive DUMMY(i) as
(
select 1 i
union all
select i+1 from DUMMY where i < 100000
)
select i , 'c1' || i , 'c2' || i, 'c3' || i, 'c4' || i, 'c5' ||
i, 'c6' || i, 'c7' || i, 'c8' || i from DUMMY;
select now(); -- 終了時刻を表示

31. 参考資料
• 検証（インデックスを先に作成）
• 実施結果は以下のようになります。
31
開始時刻 終了時刻
データ作成

32. 参考資料
• 検証（インデックスを先に作成）
• 処理前と処理後の時間を比較すると、2分以上かかっていることが分
かります。
32
開始時刻 終了時刻

33. 参考資料
• 検証（インデックスを後に作成）
• 次は、データを作成した後にインデックスを作成する場合を検証しま
す。
• テーブルを一度削除して再作成し、空の状態にしてください。
33
select now(); -- 開始時刻を表示
-- 10万件インサート
insert into itest
with recursive DUMMY(i) as
(select 1 i
union all
select i+1 from DUMMY where i < 100000
)
select i , 'c1' || i , 'c2' ||
i, 'c3' || i, 'c4' || i, 'c5' ||
i, 'c6' || i, 'c7' || i, 'c8' ||
i from DUMMY;
-- インデックス作成
create index c1_index on itest (c1);
create index c2_index on itest (c2);
create index c3_index on itest (c3);
create index c4_index on itest (c4);
create index c5_index on itest (c5);
create index c6_index on itest (c6);
create index c7_index on itest (c7);
create index c8_index on itest (c8);
select now(); -- 終了時刻を表示

34. 参考資料
• 検証（インデックスを後に作成）
• 実行結果は以下のようになります。
34
開始時刻
データ作成

35. 参考資料
• 検証（インデックスを後に作成）
• 実行結果は以下のようになります。（続き）
35
インデックス作成
終了時刻

36. 参考資料
• 検証（インデックスを後に作成）
• 今回は処理前の時間と処理後の時間を比較すると50秒程度となってい
ます。
• 環境によって誤差はありますが、今回は1分以上差が出ました。
36
開始時刻 終了時刻

37. 参考資料
• まとめ
• 今回の検証では、時間にして1分ちょっとの差しかありませんが、
データの件数が増えたり、インデックスの数が多くなるにつれて時間
の差はどんどん大きくなります。
• データ移行などで、大量のデータをインサートする場面では、イン
デックスは後で作成することを心がけてください。
37

38. 演習問題
・インデックスの作成
38

39. 演習問題
39
booksのテーブル定義
レコードの情報
レコード件数：10000件
データ分布
id：1~10000の連番
title：適当なアルファベット3文字
idにはインデックスが
作成されている
books インデックス
物理名 型 primary key 1 id
id int 〇
title varchar(50)

40. 演習問題
• 演習問題（インデックスの作成）
• 【インデックス作成方法】のページを参考に
booksテーブルのtitleカラムに対してインデックスを作成してくださ
い。
ただし、インデックス名は「 title_idx 」とする
• 作成を終えたら、インデックスが作成されていることを確認してくだ
さい。
40
-- 確認
SELECT tablename, indexname
FROM pg_indexes
WHERE tablename = 'books';

41. 演習問題
インデックスが使用されているかどうか
41

42. 演習問題
• 演習問題（インデックス使用の有無）
• それぞれのSQL文について、インデックスが使用されるかどうかを考
えてみましょう。
42
-- ①
SELECT * FROM books
WHERE id = 100;
-- ②
SELECT * FROM books
WHERE id <> 100;
-- ③
SELECT * FROM books
WHERE id BETWEEN 1 AND 1000;

43. 演習問題
• 演習問題（インデックス使用の有無）
43
-- ④
SELECT * FROM books
WHERE title = 'SQL';
-- ⑤
SELECT * FROM books
WHERE title LIKE '%QL';
-- ⑥
SELECT * FROM books
WHERE title LIKE 'SQ%';

44. 演習問題
• 演習問題（インデックス使用の有無）
44
-- ⑦
SELECT * FROM books
WHERE id = 100 OR title = 'SQL';
-- ⑧
SELECT * FROM books
WHERE id = 100 AND title = 'SQL';
-- ⑨
SELECT * FROM books
WHERE title IS NULL;

45. 演習問題
• 演習問題（インデックス使用の有無）
45
-- ⑩
SELECT * FROM books
WHERE trim(title) = 'SQL';
-- ⑪
SELECT * FROM books
WHERE substr(title, 1, 2) = 'SQ';
-- ⑫
SELECT * FROM books
WHERE title IN ('AAA', 'BBB', 'SQL');

46. 演習問題
46
novelsのテーブル定義
レコードの情報
レコード件数：10000件
データ分布
id：1～10000の連番
publisher：a1～a100 （100通り）
author ：b1～b1000 （1000通り）
title ：c1～c10000（10000通り）
novels インデックス
物理名 論理名 型 primary key 1 id
id id int 〇
publisher 出版社 varchar(50)
author 著者 varchar(50)
title タイトル varchar(50)

47. 演習問題
• 演習問題（インデックスの作成）
• 【インデックス作成方法】のページを参考に
novelsテーブルのpublisher, author, titleに対して
マルチカラムインデックスを作成してください。
ただし、インデックス名は「 multi_idx」とし、カラムの順番は
publisher, author, title の順にしてください。
• 演習問題（インデックスが使用されているか）
• 次ページ以降のSQL文でインデックスが使用されるかどうかを考え
てみてください。
47

48. 演習問題
• 演習問題（table2）
• マルチカラムインデックスの場合
48
-- ①
SELECT * FROM novels
WHERE publisher = 'a1';
-- ②
SELECT * FROM novels
WHERE author = 'b1';
-- ③
SELECT * FROM novels
WHERE publisher = 'a1' OR author = 'b1';

49. 演習問題
• 演習問題（table2）
49
-- ④
SELECT * FROM novels
WHERE publisher = 'a1' AND author = 'b1';
-- ⑤
SELECT * FROM novels
WHERE author = 'b1' AND publisher = 'a1';

50. 演習問題
• 演習問題（table2）
50
-- ⑥
SELECT * FROM novels
WHERE publisher = 'a1' AND trim(author) = 'b1';
-- ⑦
SELECT * FROM novels
WHERE author = 'b1' AND trim(publisher) = 'a1';

51. インデックスまとめ
• インデックスが使用されない条件指定まとめ
• 否定（<>）を使用している
WHERE column1 <> '100'
• 広い範囲での条件指定（ヒットする件数が多い場合）
WHERE column1 BETWEEN '1' AND '99999999'
• OR を使用している
WHERE column1 = '100' OR column2 = 'abc'
• NULLでの検索をしている
WHERE column1 IS NULL
※ただしNULLの扱いはDBMSに依存する。
51

52. インデックスまとめ
• インデックスが使用されない条件指定まとめ
• あいまい検索（後方一致）を使用している
WHERE column1 LIKE '%abc%'
• 絞り込み対象のカラムに対して演算を適用している
WHERE column1 * 1.1 = 1100
• 絞り込み対象のカラムに対して関数を適用している
WHERE TRIM(column1) = 'abc'
• CASE式を利用している
WHERE column1 = CASE
WHEN column2 = 100 then 'A'
WHEN column2 = 200 then 'B'
END
52

53. インデックスまとめ
• インデックスが使用される可能性の高い条件指定まとめ
• ＝を使用する
WHERE column1 = '100'
• 狭い範囲での条件指定
WHERE column1 BETWEEN '1' AND '100'
• 前方一致のあいまい検索
WHERE column1 LIKE 'abc%'
53

54. インデックスまとめ
• インデックスがキーに対して昇順で並んでいることを理解し、
SQLを書く際にはインデックスが使用されるSQLになっているか
を意識しましょう。
54

55. インデックスまとめ
• インデックスの設計
• インデックスを設計する際は、使用するSQL文に対してインデックス
が使用されるかどうかを考慮して設計を行いましょう。
• インデックスが多くなると、SELECT文の速度は上がりますが、更新の
負荷が増す、インデックス分の容量が必要になるなどのデメリットも
あります。
• インデックスが多くなることのメリット、デメリットを把握し、どの
ようなインデックスが必要かを考えるようにしましょう。
55

56. 参考資料
演習問題のSQLに対する実行計画
※環境によっては全く同じ状況にならない場合もあります
56

57. 演習問題の実行計画
• books - ①
• 「Index Scan」なのでインデックスが使用される。
57

58. 演習問題の実行計画
• books - ②
• 「Seq Scan」なのでインデックスは使用されていない。
58

59. 演習問題の実行計画
• books - ③
• 絞り込みの件数によって使用されるか使用されないかが異なる。
• テストデータが1万件の場合、5000件まではインデックスが使用され
る結果となった。
59

60. 演習問題の実行計画
• books - ④
• 「Index Scan」なのでインデックスが使用される。
60

61. 演習問題の実行計画
• books - ⑤
• 「Seq Scan」なのでインデックスは使用されない。
61

62. 演習問題の実行計画
• books - ⑥
• ビットマップインデックスが使用された。
• レコード件数や値のカーディナリティによってはインデックスが使用
されない場合も。
• 状況によるが前方一致の場合はインデックスが使用される可能性が高
い。
62

63. 演習問題の実行計画
• books - ⑦
• ビットマップインデックスが使用された。
• レコード件数や環境によっては「Seq Scan」の場合も。
63

64. 演習問題の実行計画
• books - ⑧
• 「Index Scan」なのでインデックスは使用される。
64

65. 演習問題の実行計画
• books - ⑨
• PostgreSQLは、nullに対してもインデックスが使用される。nullは厳密
には値ではないため、インデックスが使用されないDBMSもある。
65

66. 演習問題の実行計画
• books - ⑩
• 「Seq Scan」なのでインデックスは使用されない。
66

67. 演習問題の実行計画
• books - ⑪
• 「Seq Scan」なのでインデックスは使用されない。
67

68. 演習問題の実行計画
• books - ⑫
• ビットマップインデックスが使用される。
• レコード件数やデータ分布、環境によっては「Seq Scan」の場合も。
68

69. 演習問題の実行計画
• novels - ①
• ビットマップインデックスが使用される。
69

70. 演習問題の実行計画
• novels - ②
• 「Seq Scan」なのでインデックスは使用されない。
70

71. 演習問題の実行計画
• novels - ③
• 「Seq Scan」なのでインデックスは使用されない。
71

72. 演習問題の実行計画
• novels - ④
• 「Index Scan」なのでインデックスは使用される。
72

73. 演習問題の実行計画
• novels - ⑤
• 「Index Scan」なのでインデックスは使用される。
73

74. 演習問題の実行計画
• novels - ⑥
• ビットマップインデックスが使用される。
74

75. 演習問題の実行計画
• novels - ⑦
• 「Seq Scan」なのでインデックスは使用されない。
75

76. 演習問題の実行計画
• ちなみに
• 去年はPostgreSQLをWindows環境にインストールして検証を実施。
• その際、Bitmap Scanはなかった。
• サーバーのOSによってDBMSの実装も変わっているようなので、OSに
よっても実行計画の内容が変わる。
76

77. 演習問題の実行計画
• まとめ
• インデックスに関する知識があれば、SQL文を見ることでインデック
スが使用されるかどうかはある程度判断可能。
• しかし、実際にインデックスが使用されるかどうかは実行計画を見な
ければ分からない。
• 速度が気になるSQLは実際に実行計画を見て判断すること。
※実行計画は次回の講義で
77