【テクニカル・上級編】トランザクション分離レベルと性能 – PostgreSQL

トランザクション分離レベルが「性能」に及ぼす沈黙の代償

PostgreSQLのアーキテクチャを語る上で、避けて通れないのがMVCC（多版同時実行制御）の深淵です。多くのエンジニアが「なんとなく」で`READ COMMITTED`を使い続け、いざ大規模なトランザクションが絡むと`SERIALIZABLE`の重さに悲鳴を上げる。そんな光景を、これまで何度も見てきました。

今日は、分離レベルが単なる「整合性のルール」ではなく、PostgreSQLの実行エンジンにどのような負荷をかけ、クエリプランをどう歪ませるのか、少し深い話をしようと思います。

READ COMMITTED：PostgreSQLのデフォルトの「軽さ」の正体

デフォルトである`READ COMMITTED`は、極めて効率的です。文（Statement）ごとに新しいスナップショットを取得するため、クエリ実行の直前までのコミット済みデータしか見ない。この「短命なスナップショット」が、高い並行性を支えています。

しかし、ここで意識すべきは「Snapshotの構築コスト」です。
トランザクション内でクエリを投げるたびに、`GetSnapshotData`が呼ばれ、その時点での`ActiveSnapshot`が作成されます。高頻度でクエリを投げ続けるような処理では、このスナップショット作成のオーバーヘッドが積み重なり、意外なボトルネックになることがあります。

REPEATABLE READと「可視性判定」の重圧

`REPEATABLE READ`に上げると、トランザクション開始時のスナップショットを最後まで使い回すことになります。一見シンプルですが、内部では「可視性判定（Visibility Check）」の複雑性が跳ね上がります。

`HeapTupleSatisfiesMVCC`という関数が、すべてのタプルに対して「このタプルは私のスナップショットから見て有効か？」を判定します。このとき、もし対象行が頻繁に更新されているなら、PostgreSQLは「行バージョン」を遡り、適切なバージョンを探し出さなければなりません。

これが、いわゆる「MVCCの代償」です。HOT（Heap Only Tuple）更新が効いていればマシですが、インデックス更新を伴うUpdateが多発するテーブルで`REPEATABLE READ`を使うと、CPUがこの可視性判定だけで埋め尽くされる。スロークエリログに表れない「CPU負荷によるレスポンス低下」は、大抵このあたりが原因です。

SERIALIZABLE：最強の整合性、最大の代償

`SERIALIZABLE`に至っては、PostgreSQLは「SSI（Serializable Snapshot Isolation）」という高度な技を使っています。これは単なるロックではなく、「読み取りと書き込みの依存関係」をグラフで追跡するという、極めて数学的なアプローチです。

このモードでは、すべての読み取りデータに対して「SIReadLock」という特別なロックをメモリ上に管理します。

メモリ消費量: 膨大なクエリを投げると、ロック管理用のメモリが枯渇し、パフォーマンスが急降下します。
直列化失敗（Serialization Failure）: `40001`エラーの嵐です。アプリケーション側でのリトライロジックが必須になります。

私のアドバイスとしては、「まずは`REPEATABLE READ`で耐えられないか検討し、どうしても`SERIALIZABLE`が必要なら、そのトランザクションを可能な限り小さく分割せよ」ということです。このレベルを長時間維持するのは、DBエンジンに「無限の記憶力」を強いるようなものです。

パフォーマンストラブルシューティングの勘所

現場で「なぜか遅い」という相談を受けたとき、私はまず`pg_stat_activity`で`wait_event_type`を見ます。

もし`LWLock`の競合が頻発しているなら、それは分離レベルによって維持されている可視性情報の更新や、ロック待ちの連鎖が原因かもしれません。特に、`index_scan`が重いテーブルで分離レベルを上げると、インデックスページを辿るたびに「可視性チェック」が走り、キャッシュ効率が一気に悪化します。

解決のためのチェックリスト:
1. 不要なクエリを排除しているか？：トランザクション内で不要な`SELECT`をしていないか。
2. インデックスの肥大化を防いでいるか？：`VACUUM`が追いつかないMVCCのゴミ（Dead Tuples）は、どの分離レベルであってもスキャン性能を破壊します。
3. トランザクションは「単位」として適切か？：巨大なトランザクションは、PostgreSQLにとって最大の敵です。

最後に

PostgreSQLの分離レベルを調整することは、エンジンの心臓部に直接手を触れるようなものです。

「整合性」と「並行性能」のトレードオフは、魔法で解決できるものではありません。アーキテクチャがどうデータを走査し、どう判定を下しているのか。その裏側を想像できるようになったとき、あなたの書くSQLは、今の数倍、あるいは数十倍の効率を叩き出すはずです。

データベースは、決して無機質な箱ではありません。チューニング次第で、驚くほど軽快に、そして確実に期待に応えてくれる。それが、PostgreSQLというエンジンの面白さだと私は思っています。