アプリ開発者が知っておくべき『トランザクション分離レベル』とRead Committed の罠

PostgreSQLとSQLServerを比較しながら、Read Committedの挙動について説明します。

Transcript

1. 2026.07.26 / JPUG-Ezo#1 北海道支部リブート勉強会 アプリ開発者が知っておくべき 『トランザクション分離レベル』 と Read Committed の罠 〜 PostgreSQL と SQL Server の排他制御のギャップ 〜 三浦 恒樹（MIURA KOUKI） / 医療ITエンジニア
2. 自己紹介 - ドゥウェル株式会社 に所属（マネージャー） 医療ITエンジニア / 診療情報管理士 / 上級医療情報技師 / 医用画像情報専門技師 TypeScript / Vue.js / Node.js / Java / C# / PHP - 3兄弟の父、休日は習い事の送り迎えとか... - 参加している勉強会 札幌PHP勉強会 ゆるWeb勉強会 AWS初心者LT会in札幌 hokkaido.js さっぽろ医療IT勉強会 - コーディングBGM ラックライフ BLUE ENCOUNT SHANK Dizzy Sun Fist JBUG札幌 えびてく 札幌すごいAI会 函館本線沿線勉強会 JPUG-Ezo - Naru, 名前を呼ぶよ - Survivor, ポラリス JavaDO クラメソ札幌IT勉強会（仮） 札幌IT石狩鍋 VueSapporo
3. 1. 「同じ Read Committed」の罠 同じ分離レベルでも DB 製品ごとに挙動が異なる理由
4. 更新ロック中のSELECTの挙動差 PostgreSQL（デフォルト） SQL Server（デフォルト） • MVCC (マルチバージョン同時実行制御) を採用 • 伝統的なロックベース制御 (Shared Lock) • UPDATE処理中であっても、SELECTは「更新前のコミット済み • UPDATEが排他ロックを保持している行に対し、SELECTはブロッ バージョン」を読み取る • 読者（SELECT）が走者（UPDATE）をブロックせず、即座に結果を 返す ※MVCC = Multi Version Concurrency Control ク（待機）される • タイムアウト設定によってはロック待ちエラーが発生する
5. 更新ロック中のSELECTの挙動差 - PostgreSQL(MVCC)
6. 更新ロック中のSELECTの挙動差 - SQL Server（ロックベース制御）
7. なぜ挙動が異なるのか？ RDBMSアーキテクチャの根本的な思想差： • PostgreSQL: 行の変更時に旧バージョンを保持（xmin/xmax管 理）。SELECTはロックを要求しない。 • SQL Server: デフォルトでは行ロックによる整合性保証を重視。 • 【重要】SQL ServerのRCSI: READ_COMMITTED_SNAPSHOT オプションをONにすると、 tempdbを利用してPostgreSQLと同様のMVCC挙動に変更可 能！
8. 2. Read Committed に潜むアノマリー 「確定データしか読まない」はずなのに発生する問題 ※アノマリー=データベースの操作中に発生する望ましくない挙動や不整合
9. Read Committed で許容される現象 Non-repeatable Read Phantom Read Dirty Read (非発生) 同一トランザクション内で同じ行を2回SELECT 同一トランザクション内で範囲検索（条件指定）を PostgreSQLではRead Uncommittedを設 した際、途中で他TxがUPDATEコミットすると 2回行った際、他TxがINSERT/DELETEする 定してもDirty Readは発生しない（Read 値が変わる。 と件数が増減する。 Committedと同等処理）。
10. 実務でのトラブル例①：二重引き当て（PostgreSQL/SQLServer） Read Committed下での「在庫更新」事故 2回 同時に同じ在庫を引く 1. Tx-Aが在庫数（残数: 1）を確認して購入処理を開始 2. ほぼ同時にTx-Bも在庫数（残数: 1）をSELECTで取得 3. Tx-AがUPDATEしてコミット（在庫: 0） 4. Tx-BもそのままUPDATEを実行（在庫: -1 に突入！） → アプリで悲観的ロック (SELECT FOR UPDATE) 等が必要！
11. 実務でのトラブル例②：夜間バッチ処理中のダッシュボードタイムアウト（SQLServer） 夜間バッチ処理 ダッシュボード タイムアウト
12. 3. 解決策とアプリ側の実装戦略 隔離レベルを上げた際の「Serialization Failure」対処
13. Serializable への昇格 完全な整合性とトレードオフ PostgreSQLの Serializable (SSI) はすべてのアノマリー（Write Skewなど）を防ぎます。 しかし、直列化の整合性が破れそうになるとPostgreSQLはエラーを 返します：
14. アプリ開発者が取るべき3つの対抗策 適切な行ロックの活用: ピンポイントで整合性を守りたい場合は SELECT ... FOR UPDATE を使用する。 自動リトライロジックの実装: 40001 (Serialization Failure) 発生時は、アプリ側で指数バックオフ（Exponential Backoff）による再実行 を組み込む。 トランザクションを短く保つ: 外部API呼び出しや重い処理をトランザクション内に含めず、衝突確率を大幅に下げる。
15. まとめ ・PostgreSQLはRead CommittedでMVCC →誰かがUPDATE中でもコミット済みの状態をSELECTできる ・SQL ServerはRead Committedで行ロック制御 →誰かがUPDATE中はSELECTできない ・SQL ServerもRCSI（Read Committed Snapshot Isolation）設定可 ・すべてのアノマリーに対応する分離レベルはSerializable 隔離レベルごとのSELECT排他制御 隔離レベル / オプション PostgreSQL SQL Server (デフォルト) SELECTの排他挙動 Read Committed MVCC (標準) 行ロック制御 PG: 非ブロック / SS: ブロック(待機) RCSI (SQL Server) - tempdbでバージョン管理 PG同様に非ブロックで旧データを読有 Repeatable Read MVCC (初回スナップ) 共有ロックをコミットまで保持 PG: 他更新の競合時エラー / SS: 待機 Serializable SSI (衝突時即アボート) Range Lock (範囲ロック) アノマリー完全防止 / アプリリトライ必須