DBのindex

indexは検索を早くするためのしくみ

単純なindexとしてhash indexがある

基礎知識

InnoDBはB+ tree indexを利用している

indexをはるとsortされた状態になるので二分探索ができて早い

複合index(a, b, c)の場合は、index(b)のように扱えない。bはaで絞ったときのソートをされているため

複合インデックスから任意の1列を選んでインデックスが貼られているとして扱うことはできないということ

index(a)、(a, b)は使える

複合indexをはるときは、最もよく使う属性を一番始めaの位置に持ってくるべき

実行計画はDBのオプティマイザがたてる。このときオプティマイザはindexや統計情報を参考にする

統計情報は自動で更新されないのでたまに更新してあげるとパフォーマンス・チューニングできるかもしれない

複合インデックスの列の順番は、インデックスの使い勝手に大きな影響

複合indexはB+ tree index

https://gyazo.com/4acc31f483dabd42a2cc5b24816d557f

EMPLOYEE IDでソートした後にSUBSIDIARY IDでソートされる

SUBSIDIARY IDだけで単体のIndexとして扱うことができないことがわかる

20はいろんなところにバラけていて、ソートされていない

indexの順序でDBからエントリを取り出す

SELECT <INDEX COLUMN LIST> FROM <TABLE> ORDER BY <INDEX COLUMN LIST> FETCH FIRST 100 ROWS ONLY

ほしい行がバラバラな場合index treeが役に立っていないと判断できる

テーブルに対するインデックスの数が少ないほど、insertやdelete、updateのパフォーマンスは向上します

indexをはりまくるとこのパフォーマンスの代償がある

適切なインデックスを定義するには（略）アプリケーションがデータベースにどのようにデータを問い合わせるかを知っている必要があります。つまり、 where句に、どのような列の組み合わせが出てくるかを知っておかなければならないということです。

ORDER BY DESCによって Index Scan Backwardになるパターン

ORDER BYで複数のカラムを指定する場合の注意点として、ソートの昇順（ASC）と降順（DESC）を混在出来ないということだ。次のようなクエリでは、たとえ複合インデックスが正しいカラム順序で定義されていても、ソート処理にインデックスが使用されることはない。

事例

貼ったのに使われないケース