【テクニカル・上級編】データ検索（SELECT）の基本 – PostgreSQL

なぜ今さら「SELECT」を語るのか？――PostgreSQLの深淵を覗く

「SELECT文なんて、入社1年目でも書けるよ」。そう思うかもしれません。確かに、`SELECT FROM users WHERE id = 1;` を書くのは誰にでもできます。しかし、なぜそのクエリが速いのか、あるいはなぜ時として「悪夢のような遅延」を引き起こすのか。その内部構造を理解しているエンジニアは、意外と少ないものです。

今日は、PostgreSQLの検索の「心臓部」に触れながら、パフォーマンスを左右する現場の知見を少し掘り下げてみましょう。

—

1. FROM句の背後で起きている「物理的な戦い」

`FROM`句を書くとき、私たちは単に「テーブルを指定している」と思いがちです。しかしPostgreSQLのエンジンから見れば、それはヒープ（Heap）という名の巨大な砂場から、必要なレコードを必死に掘り出す作業です。

Sequential Scanの正体: インデックスが効かない、あるいは統計情報が古くてオプティマイザが全走査を選択した場合、PostgreSQLはテーブルの全ページを読み込みます。これはI/O負荷が非常に高い。
MVCCのオーバーヘッド: PostgreSQLは「可視性（Visibility）」のチェックを行います。`SELECT`するたびに、そのレコードが現在トランザクションから見て有効かどうかを、各行のヘッダ情報（xmin/xmax）と照らし合わせる必要がある。つまり、`FROM`は単なる読み取りではなく、常に「過去の残骸を避ける」という判断を行っているのです。

—

2. WHERE句：オプティマイザとの対話

`WHERE`句は、単なるフィルタリング条件ではありません。これはオプティマイザへの「問いかけ」です。

インデックスの選別: 単に`WHERE`に列を含めればいいわけではありません。B-Treeインデックスの左端の列（Leftmost prefix）を意識していますか？複合インデックスの順序を間違えるだけで、PostgreSQLは容赦なくインデックスを捨ててSeq Scanに切り替わります。
暗黙の型変換という罠: 例えば、`WHERE string_col = 123` と書いた瞬間にインデックスは無効化されます（暗黙の型変換）。実行計画（`EXPLAIN ANALYZE`）で「Index Cond」が出ているか、「Filter」で回されているか。この違いを常に意識するだけで、現場のトラブルシューティング速度は段違いに上がります。

—

3. ORDER BYとLIMIT/OFFSETの「隠れたコスト」

Webアプリケーションでページネーションを実装する際、`ORDER BY … LIMIT 10 OFFSET 100000` を書いていませんか？

これはパフォーマンス上の地雷です。

1. PostgreSQLは、たとえ`LIMIT 10`であっても、`OFFSET 100000`であれば、先頭から10万件分のソート処理をメモリ（`work_mem`）上で、あるいはディスク溢れを起こしながら実行します。
2. ソートがメモリに収まらない場合、`external merge disk`が発生し、パフォーマンスは劇的に悪化します。

解決のヒント: 可能な限り「Keyset Pagination（カーソルベース）」を検討してください。`WHERE id > :last_seen_id ORDER BY id ASC LIMIT 10`。これなら、インデックスを活かしてダイレクトに目的の地点へジャンプできます。

—

4. 現場で使える「診断の作法」

トラブルが起きたとき、ログを眺めるだけでは不十分です。私が現場でまず行うのは、この3つです。

EXPLAIN (ANALYZE, BUFFERS): これを使わないエンジニアは、暗闇で手術をしているようなものです。`BUFFERS`オプションをつけることで、共有メモリから読み込んだのか、ディスクから物理読み込みしたのか（Shared/Read）が手に取るようにわかります。
統計情報の鮮度確認: `pg_stat_user_tables` を見てください。`last_analyze` が古ければ、オプティマイザは間違った計画を立てます。`ANALYZE`はPostgreSQLにおける「情報の鮮度」そのものです。
pg_stat_statementsの活用: 「どのクエリが最も時間を食っているか」を定量的かつ継続的に監視する。これなしにパフォーマンスチューニングを語ることはできません。

—

最後に：データベースは「生き物」である

PostgreSQLのクエリ最適化は、パズルのような楽しさがあります。インデックスを張り、統計情報を更新し、クエリを少し書き換えるだけで、数秒かかっていた処理がミリ秒単位にまで短縮される。その瞬間の快感は、エンジニア冥利に尽きるものです。

まずは、お使いのクエリに `EXPLAIN ANALYZE` をつけてみてください。そこには、あなたが今まで知らなかったデータベースの「叫び声」が聞こえるはずです。

さあ、今日も美しいクエリを書きましょう。それではまた！