個人的メモ:Rails AntiPatterns(14)
CHAPTER 8 Scaling and Deploying
AntiPattern: Sluggish SQL
- パフォーマンス最もネックになるのはDB。indexの貼り方と副問い合わせを使った方がいいシチュエーション、ドメインモデルを使った方がいいシチュエーションを考える。
Solution: Add Indexes
- 主キーは自動的にインデックスが貼られる
- 外部キーについても基本は自動的にインデックスが貼られる。
検索で複数のカラムを主キーとして扱うような場合は、複合indexを貼ることを検討する。
- ★内容的には1対多の多側テーブルが他にも多側になる外部キー存在する場合の話をしているが、途中から複合indexの話に読めた。
uniqu識別子が付いているカラムにはインデックスをつけると早くなる。
- STIを使ってる場合、typeカラムには継承先のクラス名が入る。このtypeにはインデックスを貼ったほうがいい。
その他のカラムも検索とかで使用しているならインデックスを貼ってみるとよい。
- ★後でも書いてあるが、インデックスを貼りまくるとupdateやinsertが極端に遅くなる。特にローが多いテーブルはインデックスの追加に慎重になった方がいいというのが個人的な考え。
状態を管理するカラム、フラグ的なカラムも場合によってはインデックスを貼った方がいい。
- created_atのような日付カラムもそれを使ってorder byをしていて且つwhere句に使ってるならインデックスを貼るといい
- インデックスを貼りすぎるとupdateやinsertが遅くなる
- どのカラムにindexをつけるかは、継続的に調査する必要がある。railsのプラグインであるLimerick Rakeなどを使うか、DB自体の機能で遅いクエリを取得する機能を使うと良い。
Solution: Reassess Your Domain Modelの手前まで読了
### 関連