実行計画入門：遅いSQLを直す前に「何が重いか」を見る
この記事で分かること
- 「なぜ遅いのか」を勘で当てにせず、DBが実際にどう実行しているかを確認できる
- 実行計画（EXPLAIN）の見方の基本が分かる
- 「どの表のアクセスが重いか」「インデックスが効いているか」を判断する入口が持てる
結論：書き換えの前に実行計画を見る
遅いSQLを闇雲に書き換えても、原因が違えば速くなりません。まず実行計画で「どの処理に時間がかかっているか」を確認し、その部分（フルスキャン・重いJOIN・ソートなど）を狙って直すのが基本です。
最小例：EXPLAIN を出す
DBMSによって構文が少し違いますが、多くの場合 EXPLAIN（または
EXPLAIN ANALYZE）で計画と実測が得られます。
-- PostgreSQL の例
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 123;
-- MySQL の例
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;
- Seq Scan / Full Table Scan: 表全体を読んでいる → 条件に合う列にインデックスがあるか確認
- Index Scan / Index Range Scan: インデックスを使って絞り込んでいる → 期待どおり
- Nested Loop / Hash Join: 結合のやり方。行数が多くなっていないか確認
どこを直すかの当たりの付け方
- rows（見積もり行数）が極端に大きい → その段階で絞り込めていない
- 実際の実行時間が長いステップ → その処理（スキャン・JOIN・Sort）を減らす・インデックスを検討
- インデックスが使われていない → WHERE / JOIN の条件とインデックスの列の順序・型を確認
よくあるミス
- 実行計画を見ずに「とりあえずサブクエリをJOINに変えた」などで終わる
- 1回だけ実行してキャッシュの影響を見ていない（複数回・本番に近いデータ量で確認）
練習問題（2問）
- 手元のDBで、簡単な SELECT に EXPLAIN を付けて実行し、「どのスキャンになっているか」を読む
- WHERE の条件列にインデックスを付けて、計画が「Index Scan」などに変わるか確認する
