検索する際に、full table scanと比べて速度を向上するために使うメタデータ

1つのtable内の、1つ以上のcolumnに対して作る

大きくrecordを絞り込める検索条件が存在する場合のみ有効

実際のtableとは別に、検索に適した形にしたメタデータのtableを作る

検索する際は、そのメタデータのtableを参考にして検索する

例えば、以下のようなtableがあった時

主キーである order_id で絞り込む場合は一発で特定可能

しかし、 where price = 2500 とする場合は上から順に全record見るしか無い

そこで、以下のようにpriceでsortしたメタデータを管理するtableを別途用意する

sortされているので、全record見る必要がなくなった

このmeta tableをいくつかのレンジごとに分割するとさらに効率が良くなる

meta1 は price が 0~10000 のデータ

meta2 は price が 10000~20000 のデータ

...

とやっていけば、 where price = 11000 とした時に、 meta2 を見るだけで済む

これはまさにtree構造をやっているのと同じ

こういう感じのことをやっているのがindex

トレードオフがかなりある

追加/更新/削除する場合は、Indexも更新する必要があるため時間がかかる

検索の場合も、常に速くなるとは限らない

検索条件や、データの分布によってはfull scanした方が速いこともある

そのため、仕組みとユースケースを見比べて設計する必要がある

以下のようなcolumnは自動的にindexが作られる

主キー

外部キー

UNIQUE制約があるcolumn

そのため、これらに自分でIndexを作っても無意味

代表的なアルゴリズム

ほぼこれ

参考

概要。説明の流れがめっちゃ良い

基本

indexの本

構文

query optimizerが、indexを使うか、full scanするか判断してくれることもあるらしい

型の指定の仕方でindexの効用って変化する？

1つのtableに対し、2つのindexを作ると、2つのツリーができる？

ということは更新時にはより遅くなる？

↑で向き不向きがあるのね

B-treeはBETWEEN検索に有効

AND, OR, NOT検索はビットマップインデックスが有効

どのタイミングで更新されるのか

追加・更新・削除があると毎回創るのか

ちょっとバッジ的にまとめて更新することもできるのか

複数のインデックスを併用することってできるの？

indexを作った場合、基本的にsortしたツリーが別途作られるってこと？

sort以外にあるのかな

1table内の複数のcolumnにindexを作る

2つのcolumn AとBを一緒に where a = .. and b = ... という感じでよく使うことがあるなら有効

index (DB)の定義