ページレイアウトとスロット付きページ構造

ページが「行の住所」を安定させる理由

DB はテーブルを固定長のページ（PostgreSQL なら 8KB、InnoDB なら 16KB）の連なりとしてディスクに置きます。1ページが I/O とバッファ管理の最小単位であることは バッファプールとページ置換 や B+Tree インデックスの内部構造 で扱った通りです。ではその 1 ページの内側で、長さの違う行をどう並べるのか。素朴に「行を先頭から詰める」だけでは、ある行が伸び縮みするたびに後続の全行がずれ、その行を指していたインデックスが全て無効になります。これを避けるために考案されたのが スロット付きページ（slotted page） です。

中心となる発想は、行の物理位置（オフセット）を、外から見える行 ID から切り離す ことです。インデックスは「ページ 5 のスロット 3」を指し、スロット 3 が実際の行のオフセットを保持する。行がページ内で動いてもスロットの中身を書き換えるだけで済み、ID は不変に保たれます。PostgreSQL の ctid（(ページ番号, スロット番号) の組）はまさにこの ID で、MVCC の内部実装 で版を鎖状に繋ぐのにも使われます。

向かい合わせに伸びる二つの領域

スロット付きページは、ひとつのページを両端から使います。

+--------------------------------------------------+
| ページヘッダ (LSN, チェックサム, 空き境界など)    |
+--------------------------------------------------+
| スロット0 | スロット1 | スロット2 | ...           |  ← 先頭から下へ伸びる
|              （空き領域・free space）             |
|                          ... | 行2 | 行1 | 行0   |  ← 末尾から上へ伸びる
+--------------------------------------------------+

• スロット配列（slot array / line pointer array） はヘッダ直後から下へ伸びる。各スロットは (行本体へのオフセット, 行の長さ, フラグ) を持つ固定長の小さなエントリです。
• 行本体 はページ末尾から上へ向かって積まれる。
• 両者の間が 空き領域 で、行を 1 件挿入するたびにスロットが下へ 1 つ、行本体が上へ 1 件分伸び、空き領域が両側から削られていきます。両者が出会ったらそのページは満杯です。

スロット番号は安定、オフセットは可変

ここがスロット付きページの肝です。行を削除しても、そのスロット番号はすぐには詰めません。スロットには「無効」フラグを立てるだけで、後続スロットの番号はずらさない。番号をずらすと、その番号を指していた全インデックス・全 ctid が狂うからです。

同様に、ページ内で行本体を再配置（コンパクション）して隙間を詰めても、各スロットのオフセットを書き換えるだけで、スロット番号と行の対応は保たれます。つまりスロット番号は論理的に安定な行の識別子、オフセットは物理的に可変な実体への参照、という二層構造になっています。

行ヘッダと可変長フィールドの物理配置

1 行の中身も、ただバイトを並べるだけではありません。可変長の列を含む行は、おおむね次の順で格納されます。

[行ヘッダ][NULLビットマップ][固定長列...][可変長列の本体...]
   │            │                            │
   │            │                            └ varchar/text などの実体を後ろにまとめる
   │            └ どの列が NULL かを 1 ビットずつ
   └ MVCC 情報(xmin/xmax 等)・列数・行全体の長さ

ポイントは 可変長列を行の後方にまとめ、固定長部を前に置く ことです。固定長列は先頭からの距離が一定なので、N 番目の固定長列へは加算だけで定数時間で到達できます。一方 varchar のような可変長列は、行ヘッダ内（または可変長領域の先頭）に各列の 長さまたは終端オフセット を並べておき、それを累積して各列の開始位置を求めます。長さの前置によって、可変長が混じっても列アクセスが線形探索にならずに済むわけです。

NULL は値そのものを格納せず、行頭の NULL ビットマップ の対応ビットで表します。NULL 列は本体にバイトを一切持たないため、NULL の多い疎なテーブルは物理的にも小さくなります。これが「末尾に NULL 可の列を足す ALTER は速い」ことの一因です。

前方ポインタ：可変長更新が断片化を生む瞬間

可変長行の更新こそ、スロット付きページの最大の難所です。UPDATE で行が 伸びて 元のスロットが指す隙間に収まらなくなったとき、DB は二つの選択を迫られます。

1. 同じページに十分な空きがあれば、行をページ内の別オフセットへ移動してスロットのオフセットだけ書き換える。スロット番号は不変なのでインデックスは無傷。
2. 同じページに収まらなければ、行を別ページへ移す。このとき元のスロットには移動先 (ページ, スロット) を指す 前方ポインタ（forwarding pointer / pointer record） を残します。

問題は 2 です。前方ポインタを残すと、その行を読むたびに「元ページ → 前方ポインタ → 移動先ページ」と 2 回の I/O が要ります。ポインタの連鎖（移動先がさらに移動）を避けるため、多くの実装は前方ポインタを 1 段に制限し、再移動時は元ページのポインタを張り替えます。InnoDB はクラスタ化インデックスが主キー値で行を引くため前方ポインタは使いませんが、ヒープ構造の Oracle や SQL Server では行移動として明確に現れ、性能劣化の典型要因になります（Oracle では row migration、SQL Server のヒープでは forwarded record と呼ぶ。Oracle の row chaining は別概念で、1 行が 1 ブロックに収まらず複数ブロックに分割される現象を指す）。

断片化の二つの顔と再編成

スロット付きページで生じる断片化は、原因の違う二種類に分けて捉えると整理できます。

ページ内コンパクションは、各行本体を末尾側へ詰め直してスロットのオフセットを更新し、欠番スロットを回収する操作です。スロット番号は変わらないため安全に実行できます。PostgreSQL の VACUUM はこの回収を担い、死んだタプルの跡地を同じテーブル内の挿入に再利用します（詳細は MVCC の内部実装 を参照）。一方、行移動で物理的に散らばった行や、論理順と物理順の乖離はページ内処理では直せず、CLUSTER（PostgreSQL）や OPTIMIZE TABLE（MySQL）でテーブルごと並べ替えて書き直す必要があります。

なお、ここまでは更新を「その場で行を書き換える」前提で説明しましたが、追記専用にして断片化と前方ポインタの問題を構造ごと回避するのが LSM-Tree とログ構造化ストレージ のアプローチです。スロット付きページは更新インプレース型ストレージの基盤であり、その物理レイアウトを押さえておくと、VACUUM が必要な理由も行移動による性能劣化も、現象としてではなく原理として説明できるようになります。