「お節介な名参謀」を飼い慣らす！PostgreSQLのプランナ制御術
こんにちは！データベースの世界にどっぷり浸かって十数年、今日も今日とてSQLと向き合っているエンジニアです。
皆さんは、PostgreSQLを使っていて「なんでこのSQL、こんなに遅いの！？」と頭を抱えたことはありませんか？ データベースには「プランナ」という、SQLを実行する前に「どうやってデータを取ってくるのが一番早いか」を考えてくれる名参謀がいます。
でも、この参謀、たまに「余計なお世話」をしてくれることがあるんです。今回は、そんなお節介なプランナを、「いや、そうじゃなくてこう動いてくれ！」とスマートに指示出しするための魔法のツール、『pg_hint_plan』についてお話ししますね。
—
なぜ「名参謀」が迷走するのか？
そもそも、プランナはどうやって動いているのでしょう。実はこれ、地図も持たずに「なんとなくこっちの方が近道かな？」と勘で走っているようなものなんです。
データベースの中には「統計情報」という、データの分布を記録した手帳があります。プランナはこの手帳を頼りに、計算コストが低そうなルートを選びます。でも、データが急激に増えたり、情報の更新が追いついていなかったりすると、プランナは自信満々に「こっちが近道だ！」と遠回りなルートを案内してしまうことがあるんです。
そこで登場！「pg_hint_plan」の出番です
そんな時、私たちエンジニアが「いや、こっちの道の方が舗装されていて早いよ！」と教えるための拡張機能が『pg_hint_plan』です。
これを使えば、SQLの中に特殊なコメントを書き込むだけで、データベースの動きを無理やり制御できます。
料理に例えると…？
例えば、カレーを作るとき、「まずは野菜を炒めてから煮る」のが基本ですよね。でも、プランナが「いきなり全部鍋にぶち込んで煮るのが効率的だ！」と判断したらどうでしょう。結果は…お察しの通りですよね。
pg_hint_planは、そんな「いや、まずは玉ねぎを炒めて！」とレシピを修正する「指示書き」のようなものなんです。
—
実際にどうやって使うの？
使い方は驚くほどシンプルです。SQLの中に「ヒント」と呼ばれるコメントを埋め込むだけ。
/+
SeqScan(users)
Leading((users orders))
/
SELECT FROM users JOIN orders ON users.id = orders.user_id;
こんな風に書くと、PostgreSQLはこう解釈してくれます。
- `SeqScan(users)`：ユーザーテーブルは、インデックスを使わずに全部舐めて（シーケンシャルスキャン）持ってこい！
- `Leading((users orders))`：ユーザーテーブルと注文テーブルは、この順番で結合しろ！
「勝手に近道を探すな、俺が指定した通りに動け！」という、少し強気な命令ができるようになるわけです。
—
使いどころには少しだけ「注意」を
ここまで聞くと「じゃあ全部のSQLにヒントを書いて最強にしよう！」と思うかもしれません。でも、ちょっと待ってください！
これはあくまで「特効薬」です。
- データが変わると裏目に出る： 今は早くても、データが増えたらその「固定したルート」が実は一番遅いルートになっているかもしれません。
- メンテナンスが大変： SQLを修正するたびにヒントも書き直すのは、正直かなり面倒です。
まずは、プランナがなぜ間違えたのか？統計情報が古くないか？インデックスが足りていないのではないか？といった「根本治療」を優先してください。それでもどうしても解決しない、最後の手段としてpg_hint_planを使うのが、長く付き合っていくコツです。
—
最後に：データベースと仲良くなるために
データベースは、決して敵ではありません。プランナという優秀な参謀とどうコミュニケーションを取るか。pg_hint_planは、そんな対話のための「翻訳機」のような存在です。
ぜひ、皆さんの現場でも「あれ、こいつ分かってないな？」と思った時に、このヒントを使って優しく（あるいは厳しく）導いてあげてくださいね。
皆さんのデータベースが、今日もサクサク快適に動きますように！それではまた！
コメント