MVCC の内部実装

MVCC を「内部」から見る

MVCC（多版同時実行制御）の概念は「行を上書きせず複数バージョンを持ち、読み取りを止めない」ことです（→ ロックと MVCC）。ここでは概念の一段下、各行に隠れているメタ情報・可視性判定アルゴリズム・古い版の回収を、PostgreSQL と InnoDB の実装差を交えて掘り下げます。

要点は2つだけです。第一に、どのトランザクションも自分のスナップショットに照らして「この版は自分に見えるか」を判定する。第二に、見えなくなった古い版を誰かが**回収（GC）**しないとストレージが膨れ続ける。この2つの仕組みが製品ごとにどう違うかが、運用の勘所を分けます。

行に埋め込まれたバージョン情報

MVCC を実現するには、各行が「いつ作られ、いつ消されたか」を持つ必要があります。これがバージョンチェーンの土台です。

PostgreSQL では UPDATE が「古いタプルに xmax を書き、新しいタプルを別の物理位置に追記する」という追記型です。同じ行の歴代バージョンが本体テーブルに点在し、ctid で鎖のように繋がります。

InnoDB は逆で、本体（クラスタ化インデックス）には常に最新版だけを置きます。更新時は変更前のイメージを undo ログに退避し、行ヘッダの DB_ROLL_PTR がそこを指します。古い版が必要な読み手は、最新行から roll pointer を辿って undo を適用し直し、過去のイメージをその場で再構成します。

PostgreSQL（旧版も本体に残る追記型）
  heap: [v1 xmin=100 xmax=150] -> ctid -> [v2 xmin=150 xmax=0]

InnoDB（本体は最新、旧版は undo から再構成）
  row: [latest DB_TRX_ID=150 DB_ROLL_PTR=*]
                                  |
                            undo: [prev image TRX=100]

可視性判定：その版は「自分に見えるか」

トランザクションが行を読むとき、バージョンチェーンの各版について「これは自分から見える版か」を判定します。基準になるのがスナップショットで、ざっくり「この瞬間に確定済み（コミット済み）の世界」を表します。

PostgreSQL のスナップショットは概ね次の3要素です。これで「ある XID がスナップショット時点でコミット済みか」を判定します。

xmin : これ未満の XID は全て完了済みとみなす境界
xmax : これ以上の XID は未来（未開始）とみなす境界
xip  : xmin〜xmax の間で「まだ実行中だった」XID の集合

ある版が見えるかの判定は、おおむね次の擬似コードになります。

visible(tuple, snapshot):
  # 作成側: xmin がスナップショットから見てコミット済みか
  if not committed_before(tuple.xmin, snapshot): return false
  # 削除側: xmax が未設定、または未コミットなら、まだ生きている
  if tuple.xmax is empty: return true
  if not committed_before(tuple.xmax, snapshot): return true
  return false   # xmin/xmax ともにコミット済み = もう消えた版

つまり「作成は見える時点まで、削除はまだ見えない時点」の版だけが、自分に見える1版です。InnoDB も考え方は同じで、行の DB_TRX_ID を read view（自分のスナップショットに相当）と突き合わせ、見えなければ roll pointer を辿って見える版に到達するまで過去へ遡ります。

古い版の回収：VACUUM とパージ

可視性判定の結果「もう誰にも見えない」版は、いずれ物理的に片付けないとストレージが膨れます。ここが両者で最も性格が異なる部分です。

PostgreSQL の VACUUM は、死んだタプルが占めていた領域を同じテーブル内で再利用可能にします（ファイル自体は基本縮まらず、空きを次の追記に回す）。怠ると本体もインデックスも肥大化し、走査コストが上がります。加えて XID は約42億で一周する有限値なので、VACUUM には古い行の XID を「凍結（freeze）」してラップアラウンドを防ぐ重要な役目もあります。

InnoDB の purge は、最新版を本体に置く構造ゆえ本体は太りにくい一方、解放できない undo が溜まると undo テーブルスペースが膨張します。どちらも「最も古い読み手がどこまで遡る可能性があるか」が解放可能ラインを決めます。

実装差が運用に効く場面

同じ MVCC でも、ストレージ構造の違いがそのまま性能特性に表れます。

PostgreSQL の HOT（Heap-Only Tuple）更新は、インデックス対象列を変えない更新でインデックス更新を省き、bloat を抑える最適化です。InnoDB は「読みのたびに過去を再構成する」コストがある代わり、本体が締まっているため更新の局所性に強い、という対照になります。どちらが優れているかではなく、膨らむ場所と重くなる操作が逆だと捉えると、チューニングの当たりが付けやすくなります。

まとめ

• MVCC の心臓部は、各行の xmin/xmax（PostgreSQL）や DB_TRX_ID/DB_ROLL_PTR（InnoDB）と、スナップショットを突き合わせる可視性判定にある。
• PostgreSQL は旧版を本体に残す追記型で、掃除役は VACUUM、太るのはテーブル本体。
• InnoDB は本体に最新版だけを置き旧版をundo から再構成し、掃除役は purge、太るのは undo ログ。
• いずれの実装でも、最古の読み手が回収可能ラインを決めるため、長時間トランザクションを避けることが肥大化対策の本質。

ACID の I（独立性）が MVCC でどう支えられるかは ACID も合わせて参照してください。