■ PostgreSQL → “VACUUM”

• AUTO VACUUM がバックグラウンドで自動清掃

• 古い行バージョンを物理的に削除

• ページを再利用できるようにする

• ANALYZE と組み合わせて統計情報更新も可能

放置すると「膨張 (bloat)」が起きて動作が重くなるので重要！

■ MySQL (InnoDB) → “MVCC + Purge Thread”

• Undoログに古い行の情報を保持

• Purge thread が不要になった Undo を掃除

• ページの再利用やスペースの回収をする

PostgreSQL の VACUUM よりバックグラウンドで自動的に動く仕組み。

🧩 PostgreSQLの場合

MVCCでは各行に

• xmin（作成トランザクションID）

• xmax（削除トランザクションID）

がある。

VACUUMは：

• 全トランザクションの最小IDを確認

• それより古い不要バージョンを削除

👉 だから 長時間トランザクションがあるとVACUUMが進まない

これ、実務で超ある。

🧩 MySQL (InnoDB)の場合

• 古いバージョンはUndoログに保存

• Purge threadが不要Undoを削除

• Undo tablespaceが肥大することもある

📌 重要な設計ポイント（SRE視点）

MVCC + GC の関係で注意すべきこと：

1. 長時間トランザクションはNG

2. レプリカ遅延があるとGCが止まる場合がある

3. autovacuum設定は超重要

4. write-heavy環境ではbloat監視必須

Datadogで監視するなら：

• dead tuples

• vacuum lag

• undo history length

🎯 まとめ

MVCCだけでは完結しない。
GCがあって初めて健全なDBになる。

The following two tabs change content below.

• この記事を書いた人
• 最新の記事

小久保 暁人

最新記事 by 小久保 暁人 (全て見る)

• 202603 - 2026年3月1日
• 202602 - 2026年2月28日
• 202601 - 2026年1月26日