理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
読んだので気になった点をいくつかメモ。
全体としては、
RDBのもととなっているリレーショナルモデルの解説と、
それを軸にRDBでよく起きる問題に対する解説がされています。
タイトル通り理論が中心で読み物っぽい印象。
肝心のリレーショナルモデルは書いてあることの意味はわかるんですが、
まだまだ実感をもってはら落ちするまでできなかったので、
いつかRDBで行き詰まった時に読み直してみたいです。
以下、気になった箇所メモ。
インデックス
- インデックスは左端から順にソートされる
- 左端の文字からindexを作成していく
- WHERE LIKE "a%" => index効く
- WHERE LIKE "%a%" => index効かない
- 複合インデックスの場合も左端から順にソートされるので、カラムの並び順が重要
パーティショニング
-
範囲やキーでパーティショニングを分割
-
パーティショニングが適しているケース
-
キーのカーディナリティが低い場合
-
それ以外の場合はインデックスで十分な場合が多い
-
最新のデータへのアクセスが多いアプリの場合、日付でパーティショニングするのは有効。パーティショニングごとにindexが作成されるので
-
インデックスはクエリが決まってから検討する
-
下記の場合は、インデックスを貼らずにテーブルスキャンをしたほうがよいケースがある
-
実行頻度が低い
-
テーブルのサイズが小さい
-
検索結果が非常に多くの行にヒットする
インデックスの付け方
-
where句から
SELECT * FROM t WHERE col1 > 100 AND col2 = 'abc';
(col1, col2)の複合インデックスより、(col2, col1)のほうが効率がいい
col1 > 100 は膨大な数ヒットする可能性がある -
join,サブクエリでもインデックスは有効なので、joinする条件サブクエリのWHERE句からインデックスを検討する
ソート
- WHERE col1 = 100 AND col2 = 200 ORDER BY col3
という条件なら、インデックス(col1, col2, col3)でインデックスだけで解決できる
インデックスはcol1 -> col2 -> col3の順でソートされ作成されているので、
WHERE col1 = 100 ORDER BY col3
になると遅くなる
ORに対するインデックス
- WHERE col1 = 100 OR col2 = 200
の時は(col1),(col2)の２つのインデックスが必要。インデックスマージされ検索される
インデックスはカラムの並び順が重要
- 同じカラムの組み合わせでも並び順が異なるインデックスを作る時がよい時もある
カーディナリティ
- WHERE句でcol1,col2,col3が条件となっていても、col1,col2でカーディナリティが高ければ、(col1, col2)だけのインデックスで十分なケースもある。
- インデックスが増えれば、更新時のオーバーヘッドが発生するため。
インデックスは
- どのカラムを含めるべきか、カラムのカーディナリティ、テーブルのサイズ、更新時のオーバーヘッド、クエリの実行頻度から総合して考える
やはりインデックスとかすぐに実践できる系のやつが気になっちゃます＞＜
感謝致します。