こんにちは！データベースの世界へようこそ。
普段、PostgreSQLを使っていると、「どうしてデータベースって、こんなに遅いやり方でデータを取ってくるんだろう？」とイライラすること、ありませんか？
実は、データベースの中には「プランナ」という名の、非常に真面目だけど時々ちょっと空回りする「現場監督」が住んでいるんです。今日は、この現場監督に「今回はこうやって動いて！」と直接指示を出せる魔法のスイッチ、『プランナメソッド設定』についてお話ししますね。
—
現場監督は「効率」を常に考えているけれど…
まず想像してみてください。あなたは巨大な図書館の司書さんです。
お客さんから「『銀河鉄道の夜』という本を探して」と頼まれたとき、あなたはどうしますか？
1. 全棚を端から端まで見て回る（SeqScan：シーケンシャルスキャン）
2. 索引（インデックス）を見て、その本がどこにあるか調べてから取りに行く（IndexScan：インデックススキャン）
普通なら、迷わず「2」を選びますよね。でも、もしその図書館が「本がたったの3冊しかない小さな本棚」だったら？ 索引を探す手間の方が時間がかかるので、全部見たほうが早いかもしれません。
PostgreSQLのプランナは、まさにこの判断を常にやっています。「データ量が多いからインデックスを使おう」「データが少ないから全部見たほうが早いな」と。
でもね、時々この現場監督、「今日はちょっと調子が悪いかな？」という判断ミスをすることがあるんです。
「強制介入」という名の魔法のスイッチ
そんなとき、私たちが使えるのが「プランナメソッド設定」というツールです。これは、現場監督に対して「今回は全棚を見るのは禁止！」「絶対にインデックスを使って！」と指示を出すための設定なんです。
代表的なスイッチにはこんなものがあります：
- `enable_seqscan`：全棚探索を許可するかどうか（`off`にすると、全探索を禁止します）
- `enable_indexscan`：インデックスを使って本を探すのを許可するかどうか
例えば、特定のクエリがどうしても遅いとき、`SET enable_seqscan = off;` と打ち込んでからクエリを実行してみると、「お、劇的に速くなった！」なんてことが起こります。
注意！「毒にも薬にもなる」という話
ここまで聞くと、「なんだ、全部このスイッチで制御すれば最強じゃないか！」と思うかもしれません。でも、ここで一つ、プロからの大事なアドバイスをさせてください。
この設定、基本的には「使わない」のが一番の正解です。
なぜなら、データベースのデータ量は日々変わりますよね。今日「インデックスを使ったほうが速い」という判断が、明日データが増えたときに「やっぱり全探索のほうが速い」という結果に逆転することがあるんです。
特定のクエリに「このやり方でやれ！」と強制してしまうと、将来データが増えたときに、データベースが柔軟に対応できなくなって、かえってシステムが遅くなるという「罠」にハマってしまうことがよくあります。
どう付き合っていくのが幸せ？
じゃあどうすればいいの？と思いますよね。
1. まずは「なぜ遅いのか」を調べる：
`EXPLAIN`というコマンドを使って、現場監督がどう動こうとしているのか、まずは覗いてみてください。
2. 設定をいじるのは「最後の手段」：
インデックスを付け忘れていないか？ データの統計情報は最新か？ そういった基本をクリアにした上で、それでもなお納得いかないときだけ、一時的にこの設定を試してみてください。
3. 検証環境で試す：
本番環境でいきなり設定を変えるのは危険です。必ず手元の環境で、「本当に速くなったか？」を確認してからにしましょう。
—
データベースのチューニングは、料理の味付けに似ています。隠し味をちょっと入れるだけで劇的に美味しくなることもあれば、入れすぎて台無しになることもある。
そんな繊細な部分をいじれるようになるのは、エンジニアとしての大きな一歩です。怖がらずに、でも慎重に。ぜひ、この魔法のスイッチと仲良く付き合ってみてくださいね。
また次の記事でお会いしましょう！
コメント