読者です 読者をやめる 読者になる 読者になる

猫の魔法

主にruby系の技術メモを記載

個人的メモ:Rails AntiPatterns(14)

CHAPTER 8 Scaling and Deploying

AntiPattern: Sluggish SQL

  • パフォーマンス最もネックになるのはDB。indexの貼り方と副問い合わせを使った方がいいシチュエーション、ドメインモデルを使った方がいいシチュエーションを考える。

Solution: Add Indexes

  • 主キーは自動的にインデックスが貼られる
  • 外部キーについても基本は自動的にインデックスが貼られる。
  • 検索で複数のカラムを主キーとして扱うような場合は、複合indexを貼ることを検討する。

    • ★内容的には1対多の多側テーブルが他にも多側になる外部キー存在する場合の話をしているが、途中から複合indexの話に読めた。
  • uniqu識別子が付いているカラムにはインデックスをつけると早くなる。

  • STIを使ってる場合、typeカラムには継承先のクラス名が入る。このtypeにはインデックスを貼ったほうがいい。
    • STIは初めて知った。オブジェクトの継承関係をDBにもたす事で、継承元のcontrollerのみ書けばよくなる仕組みのよう*1
  • その他のカラムも検索とかで使用しているならインデックスを貼ってみるとよい。

    • ★後でも書いてあるが、インデックスを貼りまくるとupdateやinsertが極端に遅くなる。特にローが多いテーブルはインデックスの追加に慎重になった方がいいというのが個人的な考え。
  • 状態を管理するカラム、フラグ的なカラムも場合によってはインデックスを貼った方がいい。

    • ★普通インデックスはインデックスを貼るカラムの値がより離散していた方が効果が高い。なのでフラグカラムにインデックスを貼るとか正気かと思ったが、そのカラムが検索に使われていて、圧倒的に少ない方の値ならという話だった(それでも個人的にはSQL的にアンチパターンだと思うが)
  • created_atのような日付カラムもそれを使ってorder byをしていて且つwhere句に使ってるならインデックスを貼るといい
  • インデックスを貼りすぎるとupdateやinsertが遅くなる
  • どのカラムにindexをつけるかは、継続的に調査する必要がある。railsプラグインであるLimerick Rakeなどを使うか、DB自体の機能で遅いクエリを取得する機能を使うと良い。

Solution: Reassess Your Domain Modelの手前まで読了

### 関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法