ロックと MVCC（同時実行制御）

なぜ必要？

1人で使うだけなら順番に処理すればよく、競合は起きません。問題は同時に動くときです。たとえば在庫が1個の商品に、2人がほぼ同時に注文したとします。

-- A と B がほぼ同時に実行
SELECT stock FROM items WHERE id = 1;   -- どちらも stock = 1 を読む
UPDATE items SET stock = stock - 1 WHERE id = 1;  -- 両方が「1 - 1 = 0」にする

何も制御しなければ、2件の注文が通ったのに在庫は 0、つまり1個しかない商品が2個売れてしまいます。同時実行制御は、こうした更新の喪失（lost update）や、確定前のデータを読む（dirty read）といった異常を防ぐためにあります。隔離レベルの話とも直結します（→ トランザクション）。

ロックの基本：共有ロックと排他ロック

ロックは「このデータは今、私が使っているので待って」という札（ふだ）です。2種類を押さえれば十分です。

ポイントは「読み×読みは共存できるが、書きが絡むと独占」という点です。だから読み取りが多いシステムでは共有ロックが詰まりにくく、書き込みが多いほど排他ロックの取り合いで待ちが増えます。

悲観ロック vs 楽観ロック

「競合は起きるもの」と身構えるか、「めったに起きない」と楽観するかで戦略が変わります。

悲観ロックは、読んだ時点で行をロックして他を締め出します。

BEGIN;
SELECT stock FROM items WHERE id = 1 FOR UPDATE;  -- この行に排他ロック
UPDATE items SET stock = stock - 1 WHERE id = 1;
COMMIT;  -- ここでロック解放。後続はここまで待たされる

楽観ロックは DB の機能というより設計パターンです。行に version 列を持たせ、「読んだときの版と同じなら更新する」とします。

-- 読んだ時点では version = 5 だった
UPDATE items SET stock = stock - 1, version = 6
WHERE id = 1 AND version = 5;
-- 更新件数が 0 なら、誰かが先に更新済み → 衝突。読み直してリトライ

MVCC：読み取りをブロックしない仕組み

MVCC（Multi-Version Concurrency Control、多版同時実行制御）は、PostgreSQL・MySQL(InnoDB)・Oracle など多くの RDB が採用する中核の仕組みです。アイデアはシンプルで、データを上書きで消さず、更新のたびに新しいバージョンを作り、古い版も残しておくというもの。

各トランザクションは、自分が始まった時点の**スナップショット（その瞬間の世界）**を読みます。だから、

• 読み取りは書き込みをブロックしない：他人が更新中でも、自分は更新前の版をすぐ読める。
• 書き込みは読み取りをブロックしない：読んでいる人がいても、新しい版を作れる。

つまり「読み手」と「書き手」が互いに待たないのが最大の利点です。ロックだけの方式では、読み取りに共有ロックが必要で書き込みと衝突しがちでしたが、MVCC はそこを解消します。

デッドロック：待ち合いの膠着

ロックを使う以上、避けて通れないのがデッドロックです。互いが相手の持つロックを待ち、永遠に進めなくなる状態を指します。

トランザクションA: 行1 をロック済み → 行2 を待つ
トランザクションB: 行2 をロック済み → 行1 を待つ
→ どちらも相手の解放待ち。永久に動かない

DB はこれを検知すると、片方を犠牲者（victim）に選んで強制的にロールバックし、もう片方を進めます。中断された側はエラー（例：デッドロック検出）を受け取ります。

つまずきポイント

まとめ：どれを選ぶ？

• 読み取りが多いなら、MVCC の恩恵が大きい（多くの RDB が標準で有効）。
• 競合が少ない更新（Web の編集画面など）は、楽観ロックで待たせず、衝突時だけリトライ。
• 競合が多く正確さが命（在庫・残高）なら、悲観ロック（FOR UPDATE）で確実に直列化。
• いずれの方式でも、短いトランザクション・一定のロック順序・リトライ実装が安定運用の土台です。

OS レベルの排他制御（ミューテックスやセマフォ）とも考え方は地続きです（→ /os/concurrency-control/）。隔離レベルとの関係は トランザクション で深掘りできます。