indexの設計
基本的な方針
record数が1万以上の大規模なtableに対して作る
小さいtableの場合、インデックスるを使うよりもフルスキャンした方が高速
選択率が5~10%前後のcolumnに対して作る
ただし、常にこれだけやっていれば有効というわけでもないので注意mrsekut.icon
参考
細かいユースケースがいくつ書かれているので何度でも読むと良さそう
細かいユースケースがいくつ書かれているので何度でも読むと良さそう
そのtableのユースケースにも依存する
そのSQLに代入される値の種類にも依る
SQLの書き方にも依る
e.g. where句の選択条件、または結合条件に使用されているcolumnに作成する
使えない条件もたくさんある
中間一致や後方一致は無理
colにindexを作ったとき、where col*1.1 > 100ではIndexを有効活用できない
where col > 100/1.1とすればindexを活用できる
ORは使えない
代わりにINを使う
否定形(<>, NOT INなど)には使えない
など
どのタイミングで設計・作成すべきか
あまり明文化されていないので推測mrsekut.icon
「full scanよりもIndexを作った方が高速になる条件」を見つけたらやる
日々データが溜まっていく系のサービスなら、データが増えていき条件を満たした段階でやる
その時の、tableの使われ方や、SQLの書かれ方に合わせて作っていく
だからたぶん、tableの設計時や、プロジェクトの初期段階には作らないはず
途中で変更するコストはあるのか
例えば、再起動が必要、とか
アプリケーションのUIを工夫する
定期的なメンテを行うべき
storage上で同じ値がどの程度物理的に固まっているかを表す指標
低いほど固まっているため、アクセスするデータ量が小さくなって良い
物理的配置に依存するのであまり参考にされない(?)