「なぜか遅い…」そんな時の魔法の杖？PostgreSQLの実行計画制御と付き合うコツ
こんにちは！データベースの世界に飛び込んだ皆さん、日々SQLと格闘していますか？
PostgreSQLを使っていると、最初はサクサク動いていたはずなのに、データが増えるにつれて「あれ、なんか最近レスポンスが遅いな？」なんて感じることがあるかもしれません。そんな時、ベテランエンジニアたちが「実行計画（Explain）」という言葉を口にするのを耳にしたことがあるはずです。
今日は、その実行計画を「無理やりコントロール」してしまう、ちょっと強引だけど頼もしい設定項目についてお話しします。
—
「本棚から本を探す」ことに例えてみよう
データベースがデータを検索する様子は、大きな図書館で本を探すことに似ています。
- シーケンシャルスキャン (Seq Scan)：図書館の入り口から奥まで、一冊ずつ順番に背表紙を見ていく探し方。
- インデックススキャン (Index Scan)：図書館の目録（インデックス）を使って、目的の本がある棚番号を特定してから探しに行く方法。
基本的には、PostgreSQLという優秀な司書さんが、その時々で「今回はこっちの探し方の方が早いかな？」と判断してくれます。これを「クエリオプティマイザ」と呼びます。
しかし、時々この司書さんが「勘違い」をすることがあるんです。「全部見たほうが早いよ！」と張り切って、実はインデックスを使ったほうが早いのに、全部の棚をチェックし始めたりするわけですね。
—
「enable_」で始まる、魔法のスイッチ
そんな時、私たち人間が「いや、今は目録を使って探して！」と指示を出せるのが、`enable_` から始まる設定パラメータたちです。
- enable_seqscan: 「全部順番にチェックする（シーケンシャルスキャン）」を許可するか
- enable_indexscan: 「目録（インデックス）を使う」を許可するか
- enable_hashjoin: 「データを突き合わせる（ハッシュ結合）」を許可するか
これらを `off` に設定すると、PostgreSQLはその方法を「禁止」されます。すると、司書さんは渋々別の方法を探すことになる。これが、実行計画を制御する仕組みです。
—
⚠️ ここが大事：これは「常備薬」ではありません
ここで一つ、皆さんに強くお伝えしたいことがあります。
「じゃあ、遅いクエリがあったら全部 `off` にしてチューニングすればいいんだ！」と思うかもしれません。でも、ちょっと待ってください。これはあくまで「検証用」の道具だと考えてください。
日常的にこれらを `off` にしてしまうと、以下のような悲劇が起こります。
1. 環境の変化に対応できない：今はデータが少なくても、将来データが100倍になったとき、強制的に禁止した方法が実は一番早かった、なんてことがよくあります。
2. 他のクエリに悪影響が出る：特定のSQLを速くしようとして設定を変えたら、別の場所で「なんでそこまで遠回りするの？」というくらい遅いクエリが爆誕したりします。
このスイッチをいじるのは、「なぜ司書さんはこの方法を選んだんだろう？」という原因を突き止めるためのデバッグ作業として使うのが一番かっこいい使い方です。
—
まとめ：司書さんと仲良くするために
もしクエリが遅いなと感じたら、まずは「なぜ遅いのか？」をExplainコマンドで覗いてみてください。そして、もし「あ、インデックスが使われていないな」と気づいたら、まずはインデックスの設定を見直したり、統計情報を更新したりするのが「王道」の解決策です。
`enable_` パラメータたちは、いわば「緊急避難用のレバー」。
これを触る時は、「一時的に本当の効率を探るため」と心に留めておいてくださいね。
データベースの最適化は、パズルのようで本当に奥が深くて面白い世界です。焦らず、少しずつ司書さん（PostgreSQL）との対話を楽しんでいきましょう！
また次回の記事でお会いしましょう！
コメント