第2章：パフォーマンス・チューニング

大量のデータを扱うシステムでは、SQLの書き方一つで処理時間が数秒から数ミリ秒にまで変わります。

2-1. 実行計画（Explain）の読み方

DBMSがSQLを実行する際、どのような手順でデータを探すかを決めた「設計図」が実行計画です。SQLの先頭に EXPLAIN（PostgreSQLやMySQLなど）をつけて実行することで確認できます。

• Sequential Scan (Table Scan): テーブルの端から端まで全ての行をチェックします。データが少ない時は速いですが、大量データでは非常に遅くなります。

• Index Scan: 索引（インデックス）を使ってピンポイントにデータを探します。辞書を引くような動作で、高速です。

• Cost: DBMSが予測した処理の重さ。この数値が小さいほど効率的なクエリと判断されます。

2-2. インデックスの深化

スタンダードで学んだB-Treeインデックスを、より戦略的に活用します。

• 複合インデックス: 複数の列を組み合わせたインデックス。

  • 注意点: 列の順序が重要です。(姓, 名) の順でインデックスを作った場合、「姓のみ」の検索には使えますが、「名のみ」の検索には効果が薄くなります。

• カバリングインデックス: SELECT で必要な列がすべてインデックス内に含まれている状態。テーブル本体を見に行く手間が省けるため、極めて高速です。

• 部分インデックス: WHERE status = 'active' のように、特定の条件を満たす行だけにインデックスを貼る手法。サイズを節約し、効率を高めます。

2-3. SQLの最適化手法（アンチパターンの回避）

実行計画を良くするために、以下のような「遅くなる書き方」を避ける必要があります。

• インデックスを無効にする書き方:

  • 検索条件の列に演算を行う：WHERE salary * 1.1 > 300000（正解：WHERE salary > 272727）

  • 後方一致のLIKE検索：WHERE name LIKE '%太郎'（前方一致はOK）

  • 暗黙の型変換：数値型の列を文字列で検索する WHERE id = '123'

• IN と EXISTS の使い分け:

  • サブクエリの結果が大きい場合は、一般的に EXISTS を使う方が相関サブクエリの仕組み上、早期にスキャンを終了できて有利な場合があります。

• 不要な結合の排除:

  • 最終結果に使わないテーブルをJOINしているだけで、メモリとCPUを無駄に消費します。

2-4. 統計情報の重要性

DBMSは「統計情報（どの列にどんな値がどのくらいあるか）」を見て実行計画を立てます。

• データが大量に入れ替わった直後は、統計情報が古くなっていることがあります。

• ANALYZE 命令（DB製品による）を手動で実行し、DBMSに最新のデータの状態を教えることが、チューニングの第一歩になることも少なくありません。

第2章のまとめ

• EXPLAIN を見て、意図通りインデックスが使われているか確認する。

• 複合インデックスは「列の並び順」を考慮して設計する。

• 検索条件の列を加工しないことで、インデックスのポテンシャルを最大限に引き出す。

• 統計情報を最新に保つ運用が、安定したパフォーマンスに繋がる。