【入門編】コストベース最適化 – PostgreSQL

こんにちは！データベースの世界へようこそ。

普段何気なく使っているデータベースですが、実は裏側では毎日、ちょっとした「脳内会議」が行われていることを知っていますか？

「ユーザーさんが『東京から大阪に行きたい』って言ってる。新幹線で行くべきか、飛行機か、それとも鈍行列車か……一番安くて、早くて、疲れなさそうなルートはどれだ？」

そんな風に、データベースが最適な実行計画を練る仕組み。それが「コストベース最適化（Cost-Based Optimization）」です。今日は、このちょっと賢い仕組みについて、お話ししてみましょう。

—

例えば、100万件ある顧客リストの中から「名前が『田中』さんの人を探して！」という命令を出したとします。

データベースにとって、探し方は一つではありません。
1. 最初から最後まで、全員のリストをめくっていく（全件スキャン）
2. あらかじめ作っておいた「名前の索引（インデックス）」を使って、一発で場所を特定する（インデックススキャン）

もし「田中」さんがたった1人しかいなければ、インデックスを使うのが圧倒的に速いですよね。でも、もし「田中」さんが100万人中99万人もいたら？……わざわざ索引を引くより、最初から全員見たほうが早いかもしれません。

この「どっちが楽かな？」という判断基準が「コスト」です。

データベースが計算する「コスト」は、お金のことではありません。主に以下の2つを天秤にかけています。

データベースは、持っているデータが「どれくらいの量あるか（行数）」や「どれくらい偏っているか（分布）」という統計情報という名の「カンニングペーパー」を見ながら、「今回はインデックスを使ったほうが、ディスクを回す回数が少なくて済むから、コストが低いな！」と判断しているんです。

ここからが少し面白い（そして怖い）話です。
このコスト計算、データベースが持っている「統計情報（データの見取り図）」が最新じゃないと、とんでもない判断ミスをすることがあります。

例えば、引っ越しをしたのに古い住所録を見ているようなものです。「ここは近道だ」と思って選んだ道が、実は大渋滞の工事中だった……なんて経験、ありますよね。

データベースも同じで、データがどんどん増えているのに統計情報が古いと、「これくらいならすぐ終わるだろう」と高を括って、実はめちゃくちゃ重い処理を選んでしまうことがあるんです。これが、クエリが突然遅くなる原因の代表格です。

データベースは優秀ですが、完璧ではありません。たまには私たち人間が、「最近データが増えたから、もう一度見取り図を書き直してね！」と教えてあげる必要があります。

PostgreSQLなら、`ANALYZE`というコマンドがその役目です。これを使うことで、データベースは「あ、今のデータ状況ならこっちのルートの方が速いわ！」と計画を修正してくれます。

—

「コストベース最適化」なんて聞くと難しく感じますが、要は「データベースが自分なりに一番効率的な道筋を考えてくれている」という、頼もしい仕組みのことなんです。

もし皆さんのデータベースが最近ちょっと動きが遅いな……と感じたら、「もしかして、統計情報が古くなっていて、ルート選びを間違えているのかも？」と疑ってみてください。

その「気づき」こそが、一流のデータベースエンジニアへの第一歩です。それでは、また次回の記事でお会いしましょう！