アドベントカレンダー17日目のエントリーです。
こんにちは。開発部の山田です。
畑違いなIT業界からエコモットに転職してもうすぐ丸2年になります。
WEB開発経験がまだまだ乏しい感じではありますが、今回の記事では、普段なにげなく理解したつもりで当たり前になってしまっていることをちょっと振り返って、ちゃんと理解してみようという私の自己満足になりますが、お付き合い下さい。
今回は、たまたま担当業務でDBのテーブル設計をする機会があり、「インデックスつけるとそこまで早くなんの？？」と、ふと疑問に思ったので、試してみました。
その前に
インデックスとは
本の索引みたいなもので、人間が分厚い参考書を手にしたときに、目的のページを索引から辿っていくことで素早く目的のページに辿り着くことができるように、DBのデータに対してもこのようなインデックスを貼ることができるものです。
試しに
インデックスにも色々種類があるようですが、今回は一般的なB-tree方式について確認してみました。
環境情報
項目 情報
OS Windows 10 64bit
CPU Intel(R) Core(TM) i5-4200U CPU @1.60GHz
メモリ 8GB
DB Postgres 9.3.10
テーブル 約13,000,000レコード（総数）
まずは手始めに、
確認① WHERE条件なしで50万レコードをSELECTしてみた
インデックス付与 処理速度
なし 9330.755 ms (約9秒)
あり(適当に2つ) 8301.555 ms (約8秒)
若干の速度差は確認できたものの、劇的な速度差はないんですね。
次に、
確認② WHERE条件を指定して全件レコードをSELECTしてみた
インデックス付与 処理速度
なし 28265.566 ms (約28秒)
あり 716.727 ms (約0.7秒)
おっと！これは早いですね。
インデックスの効果を体感できたので、ちょっと満足。
じゃあ、UPDATEやINSERTは？
確認③ インデックスありなしでUPDATEしてみる
インデックス付与 処理速度
なし 6.252 ms (約0.006秒)
あり(100個) 5535.343 ms (約5.5秒)
確認④ インデックスありなしでINSERTしてみる
インデックス付与 処理速度
なし 111.873 ms (約0.1秒)
あり(100個) 5688.031 ms (約5.5秒)
極端にインデックスを100個貼った場合と比較しました。
よく、インデックスが多くなるほど、UPDATEやINSERT処理にかかる時間が遅くなると言われるのは、データを更新、登録する度にインデックスデータをその都度、再作成しているためなんですね。
確かに本の例だと、完成した本に新しいページが追加された場合、索引も作り直しだし、めちゃくちゃ時間と手間がかかりますよね。
良かれと思って貼ったインデックスの数にも要注意です。期待したパフォーマンスがでないことや、インデックスを設定したことによるデータ量の増大でディスク容量等も考慮する必要がありそうです。
終わりに
技術者たるもの、そんなことは当たり前だ！と思う方がほとんどかと思いますが、私と同じ境遇の技術者の方やこれからDBに携わる方々の一助になればと思います。最後までお付き合い頂き、有難うございました。
