データベースにおいて「クエリが遅い」という問題は、誰しも一度は直面する壁です。特にPostgreSQLのような高機能なRDBMS（リレーショナル・データベース管理システム）では、柔軟なクエリが書ける反面、その書き方次第で処理速度に大きな差が生まれてしまいます。
「少しデータが増えただけで、画面の表示が遅くなった……」
「JOINを使ったら急に重くなった……」
こうしたお悩みは、クエリの最適化によって驚くほど解消されることがあるのです。
本記事では、PostgreSQLを使ううえで知っておきたい「クエリ高速化の基本的な考え方」や「実践的な工夫ポイント」を、初心者の方にもわかりやすく丁寧に解説していきます。
これから学ぶ皆さんが、より快適なデータベース運用を実現できるよう、お手伝いできれば幸いです。
基本の見直し：クエリの書き方を最適化しよう
PostgreSQLでクエリの高速化を図るうえで、まず見直すべきは「クエリそのものの書き方」です。インデックスや実行計画の前に、そもそもそのSQL文が“効率のよい形”になっているかを確認しましょう。
以下では、初心者の方でも今日から実践できる基本的な改善ポイントをご紹介いたします。
SELECT * を使わない
「とりあえず全部取りたいから、SELECT * でいいや」
その気持ち、よくわかります。しかし、これはクエリ速度の落とし穴です。
SELECT * はテーブルの全カラムを取得するため、不要なデータまで読み込んでしまい、ネットワークやメモリに無駄な負荷をかける原因となります。
たとえば、以下のようなクエリは、
SELECT * FROM users WHERE age > 20;次のように、本当に必要なカラムだけを指定してあげるのが理想的です。
SELECT id, name FROM users WHERE age > 20;これだけでも、PostgreSQLのクエリ処理はかなり軽くなります。
WERE句の条件を最適化しよう
PostgreSQLに限らず、WHERE句の条件式が非効率だと、インデックスがうまく使われず、テーブル全体をスキャン（全件読み込み）してしまうことがあります。
たとえば、以下のような書き方ではインデックスが効きづらくなります。
WHERE DATE(created_at) = '2024-01-01'これは、created_at に関数をかけてしまっているためです。インデックスを活かすには、次のように書きましょう。
WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'このように、関数を使わずに範囲指定することで、PostgreSQLがインデックスを利用しやすくなります。
必要ないデータは取得しない
クエリが返す行数が多いほど、処理時間も長くなります。
よって、以下のように絞り込みを意識することも大切です。
-- NG: 全件取得
SELECT id, name FROM users;
-- OK: 条件で絞る
SELECT id, name FROM users WHERE status = 'active';また、大量のデータを表示する必要がない場面では、LIMITをつけるのも効果的です。
SELECT id, name FROM users WHERE status = 'active' LIMIT 100;これだけで、レスポンス速度が体感レベルで変わることも珍しくありません。
インデックスの活用
PostgreSQLでクエリの処理速度を劇的に改善する方法の一つが、「インデックス」の活用です。インデックスとは、テーブル内の特定のカラムに対して検索を速くするための“目次”のような仕組みです。
たとえば、本のページを1枚ずつめくって目的の単語を探すのと、巻末の索引から一瞬で場所を特定するのとでは、時間に大きな差がありますよね？
まさに、それと同じことがデータベース内でも起きているのです。
インデックスを使うとどう速くなるのか？
インデックスを使うと、PostgreSQLはテーブル全体をスキャンせずに、必要な行だけにピンポイントでアクセスできるようになります。
SELECT * FROM users WHERE email = 'test@example.com';この時、email カラムにインデックスがあれば、PostgreSQLは高速に対称行を探し出してくれます。インデックスがなければ、すべての行を１件ずつ調べることになり、大きなテーブルではかなりの時間を要してしまいます。
インデックスを貼るべきカラムとは？
次のような条件に当てはまるカラムには、インデックスを貼ることを検討しましょう。
ただし、インデックスは魔法の道具ではありません。貼りすぎると、データ更新時のコストが増え、逆効果になることもあります。
インデックスが効かない代表的なパターン
「インデックスを作ったのに速くならない……」というケースは意外と多いです。以下のような書き方をしていないか、ぜひ確認してみてください。
関数を使ってしまっている
-- インデックスが効かない例
WHERE LOWER(email) = 'test@example.com'計算式を含んでいる
-- インデックスが効かない例
WHERE age + 1 = 30ワイルドカードの前方一致
-- 効く：前方一致（OK）
WHERE name LIKE '山田%'
-- 効かない：前方ワイルドカード（NG）
WHERE name LIKE '%田中%'どうしても関数や演算を使いたい場合は、「関数インデックス（式インデックス）」を作成することで対処できる場合があります。
実行計画を読む：EXPLAINの基本
PostgreSQLでクエリの高速化を図るには、単にインデックスを貼るだけでなく、「そのクエリが実際にどう実行されているのか」を確認することが非常に重要です。
そのための強力なツールが EXPLAIN コマンドです。
PostgreSQLのEXPLAINを使えば、クエリの実行計画（execution plan）を確認でき、ボトルネックとなっている部分を特定する手がかりとなります。
EXPLAINとは？
EXPLAINは、SQL文の前につけることで、PostgreSQLがそのクエリをどのように処理しようとしているかを表示してくれるコマンドです。
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';このように実行すると、以下のような出力が得られます。
Index Scan using idx_users_email on users (cost=0.14..8.16 rows=1 width=100)
Index Cond: (email = 'test@example.com')
EXPLAIN ANALYZE で実行時間を確認する
単なる計画の確認ではなく、実際の実行結果も含めて確認したい場合は、EXPLAIN ANALYZEを使います。
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';このコマンドを実行すると、実際の実行時間、行数、ループ数などの詳細が表示されます。
例えば、
Index Scan using idx_users_email on users (cost=0.14..8.16 rows=1 width=100)
Index Cond: (email = 'test@example.com')
Actual time=0.023..0.026 rows=1 loops=1ここで注目すべきポイントは「Actual time」です。
これが大きい場合は、インデックスが効いていてもテーブルの設計やデータ量、他の条件に問題がある可能性があります。
JOINやサブクエリを工夫する
PostgreSQLで複数のテーブルを扱う際によく使われるのが、JOINやサブクエリ（副問い合わせ）です。しかし、これらを安易に使ってしまうと、クエリ全体のパフォーマンスが大幅に低下する原因になります。
特に、大規模テーブル同士のJOINや、ネストの深いサブクエリは、実行時間が長くなりやすく、チューニングの重要ポイントとなります。
ポイント
-- 非効率なJOIN（インデックスなし）
SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id;
-- 効率化するには、customer_idとidにインデックスを！サブクエリが遅くなる原因と対策
サブクエリ（特に相関サブクエリ）は、便利な反面、意図せずN回の問い合わせが発生することがあります。
SELECT name,
(SELECT COUNT(*) FROM orders WHERE orders.customer_id = customers.id) AS order_count
FROM customers;この場合、customers の行数分、orders テーブルに対して繰り返しアクセスが発生します。大量のデータがあると極端に遅くなります。
対策：JOIN + GROUP BYに変換
SELECT customers.name, COUNT(orders.id) AS order_count
FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id
GROUP BY customers.name;JOINと集約を使うことで、１回の問い合わせで済み、処理速度が大きく改善されます。
WITH句（共通テーブル式）で読みやすく＆高速化
PostgreSQLでは、WITH句（共通テーブル式、CTE）を使ってサブクエリを明示的に切り出すことができます。
WITH order_counts AS (
SELECT customer_id, COUNT(*) AS order_count
FROM orders
GROUP BY customer_id
)
SELECT customers.name, order_counts.order_count
FROM customers
LEFT JOIN order_counts ON customers.id = order_counts.customer_id;ポイント
まとめ
PostgreSQLでクエリ処理を高速化するには、単なる思いつきの改善ではなく、論理的な観察と設計が求められます。
「PostgreSQLのクエリが遅い」と感じたら、まずは実行計画を眺め、原因を可視化することから始めましょう。
ぜひ、本記事を参考に、あなたのPostgreSQL環境でもクエリチューニングを実践してみてください！
コメント