ガベージコレクション：MVCC バージョンのvacuumとpurge

なぜ「回収」が独立した問題になるのか

MVCC は更新を上書きではなく新しい版の追加で表現します（→ MVCC の内部実装）。この設計の必然的な代償が、誰からも見えなくなった古い版が物理的に残り続けることです。これを片付けるのが MVCC のガベージコレクション、すなわち PostgreSQL の VACUUM と InnoDB の purge です。ここではその回収器の内部、いつ・何を・どの基準で消すのかを掘り下げます。

回収の中核は1つの問いに尽きます。「この版は、現在および将来の読み手の誰からも二度と参照されないか」。一度でも参照しうる読み手が残っていれば消せません。この境界を PostgreSQL では xmin horizon、InnoDB では read view の最古点と呼びます。回収器の賢さも限界も、この境界の計算精度で決まります。

回収可能ラインの計算

回収できるのは、削除（または旧版化）した XID が「全ての生きたスナップショットから見てコミット済み」になった版だけです。判定の擬似コードは次のとおりです。

removable(dead_version):
  killer = dead_version を消した XID
  # killer が、現存する最古スナップショットより前にコミット済みなら
  # どの読み手にとっても「既に消えた版」= 回収可能
  return committed_before(killer, oldest_live_snapshot)

ここで oldest_live_snapshot（最古の生きたスナップショット）が鍵です。PostgreSQL はクラスタ全体で最も古い実行中トランザクションの xmin を集計し、それより前に消えた死タプルだけを回収対象とします。hot_standby_feedback を有効にしたレプリカや、準備済みの2相コミットトランザクションもこの境界を後ろに引っ張ります。InnoDB も同様に、最古の read view が参照しうる undo より新しいものは解放しません。

PostgreSQL：VACUUM・HOT・freeze の三層

PostgreSQL の回収は性格の異なる3つの仕事を兼ねます。

通常の VACUUM はファイルを OS に返さず、死タプルが占めた領域を同じテーブル内の空きリストに載せ、次の挿入や更新へ回します。ファイルを実際に縮めるには VACUUM FULL（テーブル全体を書き直し、排他ロックを取る）が必要で、運用では避けたい操作です。

autovacuum はテーブルごとの死タプル推定数がしきい値を超えると起動します。おおまかな式は次のとおりです。

threshold = autovacuum_vacuum_threshold
          + autovacuum_vacuum_scale_factor * 行数
死タプル数 > threshold なら autovacuum を起動

scale factor の既定は 0.2 なので、大きなテーブルほど起動が遅れ、bloat が表面化しやすくなります。巨大テーブルでは scale factor を個別に小さくするのが定石です。

HOT：そもそも版チェーンを短くする

HOT（Heap-Only Tuple）は更新がインデックス対象列を変えず、かつ同一ページ内に新版を置ける場合の最適化です。新版はインデックスから直接は指されず、旧版からページ内のポインタで辿られます。これによりインデックス更新を省け、さらに通常の SELECT 時にも不要になった中間版をその場で外す HOT pruning（軽量な版回収）が働きます。HOT が効くかどうかで bloat の進み方が大きく変わるため、頻繁に更新される列はインデックスから外す設計が有効です（→ B-Tree の内部構造）。

freeze：有限な XID を守る

XID は約42億で一周する有限値です。古い行の XID を放置すると、周回した新しい XID が「未来」と誤認され可視性判定が壊れます。これを防ぐため VACUUM は十分に古い行を「凍結（freeze）」し、常に見える版として印を付けます。

InnoDB：purge スレッドと history list

InnoDB は本体（クラスタ化インデックス）に最新版だけを置き、旧版を undo ログから再構成する方式です（→ ロックと MVCC）。回収対象は本体の死タプルではなく、不要になった undo ログレコードで、これを専任の purge スレッドが非同期に処理します。

purge の仕事は2つです。第一に、どの read view からも参照されなくなった undo レコードを解放すること。第二に、削除マーク付きのレコードを本体とセカンダリインデックスから実際に物理削除すること（InnoDB の DELETE はまず削除マークを付け、purge が後で実体を消す遅延削除です）。

未解放の undo の長さは history list length という指標に表れ、SHOW ENGINE INNODB STATUS で確認できます。これが増え続けるのは purge が最古 read view に阻まれて前進できないサインです。

長時間トランザクションが回収を止める

両エンジンに共通する最大の落とし穴が、長時間トランザクションです。読みっぱなしの BEGIN が1本でもあると最古スナップショットがそこに固定され、回収可能ラインが前進しません。

兆候の見つけ方を押さえておきます。PostgreSQL では pg_stat_activity の古い xact_start と backend_xmin、肥大化したテーブルの dead tuple 数。InnoDB では history list length の継続的な増加。どちらも「最古の読み手は誰か」を突き止め、それを終わらせれば回収が一気に進みます。

まとめ

• MVCC の回収器が消せるのは「最古の読み手から見て確実に消えた版」だけで、回収の成否は版の量ではなく回収可能ラインの位置で決まる。
• PostgreSQL の VACUUM は死タプル回収・インデックス整理・freeze による wraparound 防止の三役を担い、HOT が版チェーンの伸びそのものを抑える。
• InnoDB の purge スレッドは不要 undo の解放と削除マークの遅延物理削除を非同期に行い、停滞は history list length に表れる。
• 両者に共通する根本対策は、最古スナップショットを固定する長時間・アイドルトランザクションを排除すること。直列化可能性との関係は 直列化可能スナップショット分離 も参照。