【テクニカル・上級編】 MVCCとテーブル肥大化（Bloat） – PostgreSQL

「なぜ、PostgreSQLは突然遅くなるのか？」——MVCCとBloatが引き起こす静かなる崩壊

PostgreSQLと長く付き合っていると、一度は必ず直面する「怪奇現象」があります。

「クエリの実行計画は正しいはずなのに、なぜかパフォーマンスが落ちている」「テーブルのレコード数は変わっていないのに、フルスキャンが異常に遅い」。

もしあなたが今、そんな壁にぶつかっているなら、それはPostgreSQLの心臓部であるMVCC（多版同時実行制御）が、少しだけ「溜め込み」をしているのかもしれません。今日は、テーブル肥大化（Bloat）という、いわばデータベースの「メタボ問題」について、少し深い話をしましょう。

—

なぜMVCCは「ゴミ」を捨てないのか

PostgreSQLのMVCCアーキテクチャでは、更新（UPDATE）や削除（DELETE）が発生しても、元の行（タプル）をその場で書き換えることはしません。代わりに、新しいバージョンの行を挿入し、古い行に「これ以降は見なくていいよ」という目印（XMIN/XMAX）を付けます。

この仕組みは、同時実行制御において極めてエレガントです。ロック待ちを最小限に抑え、読み取りと書き込みが互いに干渉しない高い並行性を実現しています。しかし、ここには一つの大きな代償があります。

「不要になった古いタプル（Dead Tuple）の掃除を、誰かがやらなければならない」という宿命です。

もし掃除を怠れば、テーブルは無駄なデータで埋め尽くされます。これが「テーブル肥大化（Bloat）」の正体です。

—

Bloatが引き起こす「見えない損失」

Bloatが進行すると、データベースは物理的な容量を消費するだけでなく、性能面で非常に残酷なペナルティを課してきます。

I/O効率の致命的な低下:

PostgreSQLがデータを読み込む単位は「ページ（通常8KB）」です。Bloatが進んだテーブルでは、1ページの中に「有効なタプル」と「ゴミタプル」が混在します。結果、本来なら数ページで済むスキャンに、何倍ものページ読み込みが必要になります。ディスクI/Oは性能のボトルネックの筆頭です。

インデックスの肥大化:

これは意外と見落とされがちですが、インデックスもまたMVCCの影響を受けます。インデックスの構造の中に死んだエントリが溜まると、インデックススキャンの深さ（ツリーの階層）が深くなり、ランダムI/Oの回数が増加します。

キャッシュ効率の悪化:

メモリ上のバッファキャッシュが「ゴミ」で占有されます。本来、本当に必要なホットデータが載るべき場所に、もう誰もアクセスしない古いタプルが居座る。これはメモリ資源の浪費であり、スループットの低下に直結します。

—

VACUUMという名の「掃除人」との付き合い方

PostgreSQLエンジニアにとって、`VACUUM`は単なるメンテナンスコマンドではなく、生命維持装置です。

自動バキューム（Autovacuum）があるから安心……と思っていませんか？確かにAutovacuumは優秀ですが、高頻度な更新が行われる巨大テーブルでは、設定値がデフォルトのままでは追いつきません。

現場で気をつけるべきチェックポイント：

1. 統計情報の鮮度: `pg_stat_user_tables` の `n_dead_tup` を常に監視してください。ここが異常に高いなら、Autovacuumの閾値（`autovacuum_vacuum_scale_factor` など）が適切ではないサインです。
2. ロングトランザクションの排除: 最も恐ろしいのは、長生きするトランザクションです。PostgreSQLは「現在進行中の最も古いトランザクション」より前のタプルしか物理削除できません。1つでも長時間残るトランザクションがあると、VACUUMはどれだけ頑張ってもゴミを捨てられず、テーブルは肥大化の一途をたどります。
3. インデックスの掃除: `VACUUM`はメインテーブルを掃除しますが、インデックスの肥大化はまた別の話です。場合によっては `REINDEX CONCURRENTLY` を使った計画的なメンテナンスも検討の余地があります。

—

まとめ：データベースは「生き物」である

PostgreSQLというデータベースは、非常に賢い設計ですが、魔法の箱ではありません。MVCCがもたらす高い並行性の裏側には、常に「ゴミ掃除」というコストが隠れています。

チューニングの基本は、クエリをいじることだけではありません。「物理レイヤーで何が起きているか」を想像することです。

もし、システムが少し重いなと感じたら、`pgstattuple` などの拡張機能を使って、テーブルのBloat率を一度覗いてみてください。想像以上に「ゴミ」が溜まっているかもしれません。それを適切に管理してあげることこそが、最高峰のエンジニアがPostgreSQLに対して行うべき、最高の敬意の払い方だと私は思います。

さて、あなたのDBは今日、どれくらい「身軽」でしょうか？