自分用に要約メモ。
詳しい記事は引用先をみてくださいな。
@see なぜ、SQLは重たくなるのか? —『SQLパフォーマンス詳解』の翻訳者が教える原因と対策
- ORMが自動生成するSQLを確認する
通常はSELECT+JOIN句で処理できるSQL対して、N+1問題が発生していないか。
10記事取得するSQLで、
記事取得で終わるSQL一発が、記事取得1+各記事に紐づくタグ取得10回の11回のSQLが発行されていないか…etc - 複合インデックスの不適切使用
2カラムについて複合インデックスを指定しているテーブルは、WHERE句で2カラム複合インデックスを指定する。1カラムしか指定できていない。 - 複合インデックスの走査範囲。優先順位の不適切な指定
数が少ないカラムから指定する。
『部署』と『誕生日』であれば、『部署』の方が少ない(はず)。部署から先にWHEREで指定する。 - LIKE検索での前方ワイルドカード
前方のワイルドカードではインデックスが効かない - テーブル結合が苦手なDBMS
MySQLはテーブル結合が苦手。PostgreSQLを使おう - ORDER BY, GROUP BYで使うカラムはインデックスを
インデックスを張ったカラムに対して使おう。そうでないとソートが必要になり、メモリやCPUを大量に使う。 - データがメモリに載るサイズで設計する
2年後のDBサイズを予想し、ハードウェアを利用するDBのサイズに対して合わせる。 - 複数クエリの総実行時間
処理が軽い、頻繁に発行されるクエリがないか。
あれば数を減らす、スマートにまとめられないか。
“10秒かかるクエリを1分間に1回実行”する処理が重たいがたまに発行されるクエリより、
“0.1秒かかるクエリを1秒に10回、60秒実行”するほうがCPUに対する継続的負荷がかかる。