目次
sqlのwhere句で使用しているカラムにindexを張ると検索が早くなる理由
結論
イメージ
複合indexを張った場合にできるキーとアドレスのテーブルのイメージ
indexを張ると逆に処理が遅くなってしまう場合
キーがやたらと被っている場合のイメージ
indexは張れば張るだけ検索が早くなるわけではない
SQLのWHERE句で使用しているカラムにIndexを張ると検索が早くなる理由
結論
「Indexを付けたカラム（キー）」で二分探索ができるようになるから
イメージ
1
以下のように、商品テーブルがあったとする。
その商品テーブルの商品名カラムにIndexを張る。（商品名がキーとなる）
商品テーブル
- この時のキー（Indexを付けたカラム）の順番はバラバラ（昇順や降順に並べられていない）で、値が重複している可能性がある
- キー（Indexを付けたカラム）は、テーブル定義の「主キー」や「複合キー」とは違う意味
- アドレスはレコードの場所を示すため、重複しない
2
Indexを張ると、キー（Indexを張ったカラム）とアドレスのテーブルが作られる。
この時、キー（Indexを張ったカラム）は、昇順か降順に並べられて登録される。
（アドレスの順番はバラバラ）
これで二分探索を行う準備が整う。
Indexを張ったことにより作成された、キー（Indexを張った商品名カラム）とアドレスのテーブル
- あくまでもIndexを張ったら、二分探索をする準備（キーアドレスのテーブル作成）を行うだけ
4
「商品名が『ノート』のレコードが欲しい！」となった場合
キー（Indexを張った商品名カラム）とアドレスのテーブルに、キー（商品名）が昇順（五十音順）に並んでいるため、二分探索が使える。
つまり、テーブルを端から総舐めするより検索が早い！！
5
4でキー（Indexを張った商品名カラム）とアドレスのテーブルから「ノート」が見つかったら、「ノート」と一緒に登録されているアドレスを使って、商品テーブルのアドレスに飛ぶ。
このことにより、商品名が『ノート』のレコードが取得できる。
- インデックス検索は、キーを見つけたらキーに紐づくアドレスを使って、実際のテーブルのアドレスに飛ぶ
複合Indexを張った場合にできるキーとアドレスのテーブルのイメージ
キー1の塊の中で、キー2が昇順か降順になる
Indexを張ると、逆に処理が遅くなってしまう場合
キーがやたらと被っている場合や、まとまったデータを取得するときは、Indexを使うと使わないよりも遅くなってしまう場合がある
キーがやたらと被っている場合のイメージ
Index検索は、キーを見つけたらそれに紐づくアドレスを使って、実際のテーブルのアドレスに飛ぶという処理が必要
実際のテーブルのアドレスに飛ぶ回数が多くなると、処理が遅くなってしまう。
そのため、このような場合は、実際のテーブルに飛ぶという処理が発生しない（Indexを張らない）データ総舐めの方が早かったりする。
（実施のテーブルだけを使って、上から順に検索をかけて、見つけ次第データを抜いていくだけになる）
- Indexは、1個ずつのデータの取得は得意だが、まとまったデータの取得は苦手
- 例えば「テーブルのデータを半分ちょうだい」となったら、Indexを使わない方が処理が少ない分早かったりする
Indexは張れば張るだけ検索が早くなるわけではない
よくWHERE句で使っているカラムにIndexを張ると検索が早くなると言われる。
しかし、Indexを複数張っても基本的に1つしか使われない。（複合Indexは話が別だけど）
そのため、複合Indexではなく単独でIndexを張りまくると、使われないIndexが出てくる。
使われないIndexはただのゴミデータとなってしまう。
また、Indexを張ると張った分だけINSERT文やUPDATE文が必然的に遅くなる。
理由：INSERT文やUPDATE文を使うと、Indexのテーブルにも変更を加えなくてはいけない。
（Indexを張ると、張った分だけテーブルの数が増える）
以上のことから、Indexの仕組みを理解せずに「Indexを使うと早くなるので、全部のカラムにIndexを付けてしまおう！！＼(^o^)／」というのはよろしくない。