SQL, チューニング

SQLパフォーマンス要約 なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策

 

自分用に要約メモ。

詳しい記事は引用先をみてくださいな。

@see なぜ、SQLは重たくなるのか? —『SQLパフォーマンス詳解』の翻訳者が教える原因と対策

 

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

 

 

YouTube

【寿司打チャレンジ】天才プログラマーがタイピングに挑戦!

自責? おまえ嘘つくなよ

フリーターから正社員 インフラは2か月!

インフラにプログラミングは必要 SREのすすめ

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)