開発をしていると、
- SQLの実行が遅い
- 一覧画面の表示に時間がかかる
- データ量が増えるにつれてレスポンスが悪くなる
といった場面は少なくありません。
最初は問題なく動いていても、データが増えると急に遅くなることがあります。
そんなときに確認したいのが、
- Index（インデックス）
- EXPLAIN
- ANALYZE
です。
この記事では、SQLのパフォーマンスを改善する際によく確認しているポイントを紹介します。
まずはEXPLAINを見る
SQLが遅いからといって、すぐにインデックスを追加することはありません。
まず実行計画を確認します。
例えば、
EXPLAIN
SELECT *
FROM users
WHERE email = 'sample@example.com';
実行計画を見ることで、
- どのIndexを利用しているか
- テーブル全件検索になっていないか
- JOINの順番
などを確認できます。
まずは現状を把握することが重要です。
Full Table Scanになっていないか
例えば、
type: ALL
となっている場合は、
テーブル全体を検索している可能性があります。
データ量が少ないうちは問題ありませんが、
数百万件になるとレスポンスへ影響することがあります。
Indexを追加する
検索条件によく利用するカラムには、
Indexを追加します。
例えば、
CREATE INDEX idx_users_email
ON users(email);
これにより、
WHERE email = ?
の検索が高速になります。
複合Index
複数カラムで検索する場合は、
複合Indexも検討します。
例えば、
SELECT *
FROM users
WHERE company_id = 1
AND status = 'active';
なら、
CREATE INDEX idx_company_status
ON users(company_id, status);
のようなIndexを作成します。
Indexは順番も重要
複合Indexでは、
カラムの並び順も重要です。
例えば、
(company_id, status)
のIndexは、
WHERE company_id = ?
でも利用できます。
一方、
WHERE status = ?
だけでは利用できないケースがあります。
検索条件に合わせて設計することが重要です。
ANALYZEで実際の実行時間を確認
実行計画だけでなく、
実際の実行時間も確認します。
例えば、
PostgreSQLでは、
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE company_id = 1;
を実行します。
実際にSQLを実行した結果が表示されるため、
予測だけでは分からないボトルネックも確認できます。
実行計画を比較する
Index追加前
Seq Scan
Execution Time
1500 ms
Index追加後
Index Scan
Execution Time
12 ms
このように、
Indexが利用されることで、
大きく改善するケースもあります。
ORDER BYにも注意
例えば、
SELECT *
FROM users
ORDER BY created_at DESC;
のようなSQLでは、
created_atにIndexがないと、
ソート処理が重くなることがあります。
一覧画面などではよく確認しています。
SELECT *を避ける
必要なカラムだけ取得することも意識しています。
例えば、
SELECT id, name
FROM users;
不要なデータを取得しないことで、
転送量やメモリ使用量を抑えられます。
Indexを増やしすぎない
Indexは検索を高速化できますが、
増やせば良いというものではありません。
Indexが増えると、
- INSERT
- UPDATE
- DELETE
時の更新コストも増えます。
検索頻度と更新頻度を考えて設計することが大切です。
実際に意識していること
SQLが遅いと感じたら、
次の順番で確認しています。
- EXPLAINを見る
- Full Table Scanになっていないか確認
- Indexが利用されているか確認
- 必要ならIndexを追加
- EXPLAIN ANALYZEで改善を確認
いきなりIndexを追加するのではなく、
実行計画を確認してから対応するようにしています。
まとめ
SQLのパフォーマンス改善では、
- EXPLAINで実行計画を確認する
- 必要に応じてIndexを追加する
- EXPLAIN ANALYZEで効果を確認する
という流れを意識しています。
Indexは非常に効果的ですが、適切な場所へ設計することが重要です。
実行計画を確認しながら改善することで、根拠を持ってチューニングできるようになります。