章: 第4章: データ整合性と運用
送金処理の途中でエラーが起きたら、どうなりますか?
口座Aから500円を引いた瞬間にエラーが発生し、口座Bへの加算が行われなかった——こんな事態を防ぐのがトランザクションです。複数の更新をひとつの「まとまり」として扱い、全部成功するか、全部なかったことにする仕組みです。
トランザクションなしでは何が起きるか
トランザクションを使わずに複数テーブルを逐次更新すると、途中の失敗で「中途半端な状態」のデータが残ります。この状態を整合性の崩れと呼び、後から手動で直すことは非常に困難です。
トランザクションの効果:使う場合・使わない場合の比較
| 状況 | トランザクションなし | トランザクションあり |
| 途中でエラーが発生 | 中途半端な更新が残る | ROLLBACKで全取消 |
| 正常終了 | 各更新が個別にコミット | COMMITで全確定 |
| 例外処理との連携 | 手動で補正が必要 | ROLLBACK1回で戻せる |
| 整合性の保証 | 保証なし | ACIDプロパティで保証 |
チェックポイント: トランザクションは必ず例外処理とセットで書きましょう。
START TRANSACTIONを書いたら、成功時のCOMMITと失敗時のROLLBACKを両方実装してから動作確認します。COMMITだけ書いてROLLBACKを忘れるミスがよくあります。
コードサンプル
START TRANSACTION;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;
-- 失敗時は ROLLBACK;
まとめ & 次のステップ
- トランザクションを使うと複数更新を「全部成功か全部取消」に守れます
- 途中失敗時のROLLBACKで整合性が保たれます
- 例外処理とセットで書くことを習慣にしましょう
- START TRANSACTION〜COMMITの範囲は必要最小限に絞り、長いトランザクションはロックを長引かせます
- 本番では異常ケースを意図的に作り、ROLLBACKが機能するか事前に確認しましょう
次回は 分離レベルとロックの考え方 を学びます。同時実行時の読み取り一貫性と競合をどう制御するかを理解しましょう。