トランザクション基礎

RDB の信頼性はトランザクションで支えられます。 「受注登録と在庫更新は同時に成功/失敗させるべき」「送金の引き落としと入金は片方だけ実行されてはいけない」 ――こうした要求を実現する仕組みがトランザクションです。

トランザクションとは

トランザクションは、複数のSQL文をひとまとまりの作業単位として扱う仕組みです。 すべて成功すればコミット（確定）し、途中で失敗すればロールバック（全取消）します。

基本構文

BEGIN;  -- トランザクション開始

UPDATE account SET balance = balance - 10000 WHERE account_id = 'A001';
UPDATE account SET balance = balance + 10000 WHERE account_id = 'B002';

COMMIT; -- 両方成功 → 確定

BEGIN;

UPDATE account SET balance = balance - 10000 WHERE account_id = 'A001';
UPDATE account SET balance = balance + 10000 WHERE account_id = 'B002';
-- ↑ ここでエラー発生

ROLLBACK; -- 全取消（A001の引き落としも元に戻る）

業務での例

ACIDの詳細

トランザクションが満たすべき4つの性質をACIDと呼びます。

Atomicity（原子性）

トランザクション内の操作はすべて成功するか、すべて失敗するかのどちらかです。中途半端な状態は残りません。

Consistency（一貫性）

トランザクションの前後で、DB上の制約（PK/FK/CHECK/UNIQUE等）がすべて満たされた状態を維持します。制約に違反する操作はトランザクション全体が拒否されます。

-- 在庫数が負になるとCHECK制約に違反 → トランザクション失敗
BEGIN;
UPDATE inventory SET quantity = quantity - 100
  WHERE product_id = 'P001'; -- 在庫が50しかない場合
-- CHECK (quantity >= 0) 違反 → ROLLBACK

Isolation（分離性）

同時に実行される複数のトランザクションが互いに干渉しないように制御します。あるトランザクションの途中結果が、他のトランザクションから見えないようにします（分離レベルにより程度が異なる）。

Durability（永続性）

コミットが完了したデータは、直後にシステムがクラッシュしても失われないことを保証します。RDBMSはWAL（Write-Ahead Logging）などの仕組みで、コミット済みデータをディスクに永続化します。

同時実行で起きる問題

分離性が不十分だと、同時実行で以下の問題が起きます。

ダーティリード（Dirty Read）

他のトランザクションがまだコミットしていない変更を読んでしまう問題です。

-- Tx-A: 在庫を100→50に更新（まだCOMMITしていない）
-- Tx-B: 在庫を読む → 50と見える
-- Tx-A: ROLLBACK（在庫は100に戻る）
-- Tx-B: 50を前提に処理を続行 → 不整合

ノンリピータブルリード（Non-Repeatable Read）

同じトランザクション内で同じ行を2回読んだら値が変わっている問題です。

-- Tx-A: 商品P001の単価を読む → 1200円
-- Tx-B: 商品P001の単価を1500円にUPDATE → COMMIT
-- Tx-A: 同じ商品P001の単価をもう一度読む → 1500円（変わった！）

ファントムリード（Phantom Read）

同じ条件で検索したら、前回なかった行が出現する（または消える）問題です。

-- Tx-A: SELECT COUNT(*) FROM orders WHERE order_date = '2026-02-16' → 10件
-- Tx-B: INSERT INTO orders (...) → COMMIT（1件追加）
-- Tx-A: 同じSELECT → 11件（増えた！）

ロストアップデート（Lost Update）

2つのトランザクションが同じ行を読んで更新し、片方の更新が上書きされて失われる問題です。

-- 在庫: 100
-- Tx-A: 在庫を読む → 100。 100 - 30 = 70 を書き込む準備
-- Tx-B: 在庫を読む → 100。 100 - 20 = 80 を書き込む準備
-- Tx-A: UPDATE → 70
-- Tx-B: UPDATE → 80（Tx-Aの -30 が消えた！正解は 50）

分離レベル

SQL標準では4段階の分離レベルが定義されています。レベルが高いほど安全ですが、性能への影響も大きくなります。

分離レベルと防げる問題のマトリックス

主要RDBMSのデフォルト分離レベル

分離レベルの設定例

-- セッション単位で変更
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- PostgreSQLでトランザクション単位で変更
BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- ... 処理 ...
COMMIT;

ロックの基礎

分離性を実現する主要な仕組みがロック（施錠）です。

共有ロックと排他ロック

ロックの粒度

楽観ロックと悲観ロック

-- 悲観ロックの例
BEGIN;
SELECT * FROM inventory WHERE product_id = 'P001' FOR UPDATE;
-- ↑ この行は他のトランザクションからUPDATEできなくなる
UPDATE inventory SET quantity = quantity - 10 WHERE product_id = 'P001';
COMMIT;

-- 楽観ロックの例（アプリ側で実装）
-- 1. 読み取り時にバージョンを取得
SELECT quantity, version FROM inventory WHERE product_id = 'P001';
-- → quantity=100, version=5

-- 2. 更新時にバージョンを条件に含める
UPDATE inventory
   SET quantity = 90, version = 6
 WHERE product_id = 'P001' AND version = 5;
-- → 更新件数が0なら「他者が先に更新した」と判断してリトライ

デッドロック

2つ以上のトランザクションが互いに相手のロック解放を待ち合って永久に進まなくなる状態です。

発生メカニズムの例

RDBMSの対処

ほとんどのRDBMSにはデッドロック検出機構があり、検出すると一方のトランザクションを強制ロールバックして解消します。 アプリ側はそのエラーを受け取ったらリトライするのが定石です。

回避策

1. ロック順序を統一する: 全トランザクションで商品IDの昇順にロックを取ると決めれば、循環待ちは起きない
2. トランザクションを短くする: ロック保持時間を最小化する
3. 大きな粒度のロックを避ける: テーブルロックよりも行ロックを使う
4. タイムアウトを設定する: 一定時間で諦めてリトライする

トランザクション境界の設計

アプリケーション層では「どこからどこまでを1つのトランザクションにするか」を明確に設計する必要があります。

原則: 1業務操作 = 1トランザクション

業務的に「一緒に成功/失敗すべき操作群」を1トランザクションにまとめます。

長すぎるトランザクションの問題

• ロック保持時間が長くなる: 他のトランザクションがブロックされ、スループットが低下する
• ロールバック時のコストが大きい: 大量の変更を巻き戻すのに時間がかかる
• MVCC環境でも負荷が増える: 古いバージョンのデータを長時間保持する必要が生じる

トランザクション外に出すべき処理

• 外部API呼び出し（決済API、メール送信など）: タイムアウトでトランザクションが長期化するリスクがある
• 重いファイル処理: トランザクション内でロックを保持したまま時間がかかる

-- 良い例: 外部API呼び出しはトランザクションの外
BEGIN;
  INSERT INTO orders (...) VALUES (...);
  UPDATE inventory SET quantity = quantity - 10 WHERE ...;
COMMIT;

-- コミット成功後に外部API呼び出し
call_payment_api(order_id);

-- API失敗時は補償トランザクション（取消処理）で対応

実務のベストプラクティス

1. トランザクション内でユーザー入力を待たない

BEGIN → SELECT FOR UPDATE → ユーザーの確認画面 → UPDATE → COMMIT のような設計はロック保持時間が不定になり、他の処理を長時間ブロックします。 ユーザー入力は楽観ロックで対応し、DB操作は一気に行うのが基本です。

2. タイムアウトを設定する

-- PostgreSQL: ロック待ちタイムアウト
SET lock_timeout = '5s';

-- MySQL: InnoDBのロック待ちタイムアウト（秒）
SET innodb_lock_wait_timeout = 10;

3. デッドロック時はリトライする

デッドロックでロールバックされたら、同じ処理をリトライします。アプリ層でリトライ回数（通常3回程度）と待機時間（指数バックオフ）を設計します。

4. コネクションプールとトランザクションの関係を意識する

コミット/ロールバック忘れでコネクションが返却されると、ロックが残り続けるリスクがあります。フレームワークのトランザクション管理機構を使うか、try-finally で確実に終了させます。

// アプリ層の疑似コード
try {
    connection.beginTransaction();
    // ... DB操作 ...
    connection.commit();
} catch (Exception e) {
    connection.rollback();
    throw e;
} finally {
    connection.close(); // プールへ返却
}

5. 読み取り専用処理はREAD ONLYを宣言する

BEGIN READ ONLY;
SELECT ... ;  -- 書き込みロックを取らないのでブロックしにくい
COMMIT;