参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 5章, 6章
達人に学ぶDB設計 徹底指南書
論理設計とパフォーマンス
正規化の功罪
- 整合性を保つことはできるが、検索が遅くなる
正規化とSQL
- 内部結合では相手側のテーブルに対応するレコードがない場合情報が漏れてしまうのでこの時外部結合を使う
- 非正規科ではれば結合を使わず検索できる
- 更新処理では正規化のほうが早い（非正規化であれば対応する全てのレコードを更新する必要があるため
- 非正規化はあくまで最後の手段である
- サマリデータを用いることで結合を回避する方法もある
データベースとパフォーマンス
インデックス
- B-Treeインデックスは平均点が高く扱いやすい
- B-Treeが効果を持たない検索条件は否定条件
- 以下の処理では暗黙にソートが行われる
- 集約関数
- COUNT, SUM, AVG, MAX, MIN
- ORDER BY 句
- 集合演算
- UNION, INTERSECT, EXCEPT
- OLAP関数
- RANK, ROW_NUMBERなど
- 集約関数
- インデックスは構築時にソートしているためインデックスをキーとして含んだ処理ではソートがスキップされる
インデックスの設計方針
- 大規模なテーブルに対して作成する
- データ量が少ない場合インデックスよりもフルスキャンの方が早い
- 差はごくわずかであるがそれならばわざわざ無駄なインデックスを作る必要はない
- 最近のハードウェアなら1万件以下の場合はほぼ効果ないと考えられる
- カーディナリティの高い列に作る
- 特定の列の値がどのくらいの種類の多さを持つか
- 月ならばカーディナリティは12など
- 複合列に対してインデックスを作成する場合、対象の複合列の組み合わせで考える
- 先頭に近いキーのカーディナリティが高いほど効果的
- カーディナリティが高くても特定の値にデータが集中しているような列には向いていない
- SQL文でWHERE句の選択条件、または結合条件に使用されている列に作成する
- IS NULL, 否定, ORはインデックスが利用されてない
- 主キーおよび一意制約の列には作成不要
- 更新性能が劣化するため無駄なインデックスは作らない方が良い
