SQL Server のトランザクション入門 — BEGIN TRAN / COMMIT / ROLLBACK と分離レベルを業務SEが本番事故なしで使う

みなさんこんにちは！ヒロポンです！

夜のバッチで複数テーブルを更新したら、途中でエラーになって片方だけ反映されてた。気付いたのは翌朝。

在庫は減ってるのに受注は確定してない。そういうズレ。

これ、俺もやりました。流通系の基幹システムの保守をやってた頃、夜中に呼び出されてデータを手で復旧したことがあります。

整合性を戻すのに3時間。正直、心が折れかけました。

この事故を防ぐのがSQL Server トランザクションです。「複数の更新をひとまとまりにして、途中で失敗したら全部なかったことにする」しくみ。

この記事は、BEGIN TRANSACTION / COMMIT / ROLLBACK の基本から、TRY...CATCH で確実に巻き戻すテンプレ、最後に分離レベルの選び方まで、業務SEが本番でやらかさない順に積み上げていきます。

トランザクションが解決する問題 — なぜ「途中で失敗」が怖いのか

まず、なんでトランザクションが要るのか。

たとえば「在庫を1減らす」「受注を確定にする」の2つの UPDATE。これ、別々に実行すると、1つ目が通って2つ目がコケた瞬間にデータが宙ぶらりんになります。

-- ❌ バラバラに実行: 2つ目が失敗すると整合性が壊れる
UPDATE dbo.Stock  SET Qty = Qty - 1    WHERE ProductId = 100;
UPDATE dbo.Orders SET Status = 'Fixed' WHERE OrderId = 5001;  -- ここで落ちたら?

業務システムって「在庫と受注は必ずセットで動く」みたいな前提が山ほどある。片方だけ動くと、その前提が崩れる。

トランザクションは、この「全部やるか、全部やらないか（All or Nothing）」を保証するための機能です。COMMIT で確定、ROLLBACK で全取り消し。これだけ。

トランザクションの基本: BEGIN TRANSACTION / COMMIT / ROLLBACK

最小の雛形がこれです。コピペして、テーブル名と条件だけ差し替えてください。

BEGIN TRANSACTION;

UPDATE dbo.Stock  SET Qty = Qty - 1    WHERE ProductId = 100;
UPDATE dbo.Orders SET Status = 'Fixed' WHERE OrderId = 5001;

COMMIT TRANSACTION;   -- 両方成功したら、ここでまとめて確定

BEGIN TRANSACTION から COMMIT までが「ひとまとまり」。

この間の更新は、COMMIT するまで他のセッションから見ればまだ起きてないことになってます。

ん？コミットするまで他からは見えへんの？？ そう、見えないんです。だから途中経過を他人に踏ませずに済む。

BEGIN TRAN と略してもOKです。手で叩く時は短いほうが楽。

途中でおかしいと気付いたら、COMMIT の代わりに ROLLBACK TRANSACTION; を打つ。すると BEGIN 以降の更新が全部なかったことになります。これがいい感じに効くんですよね。

ただ、本番の手作業ならともかく、ストアドやバッチに組み込むなら「エラーが出たら自動で巻き戻す」までセットにしないと意味がない。次にいきます。

エラーで確実に巻き戻す: TRY…CATCH と XACT_ABORT

COMMIT に辿り着く前に例外が飛んだら、誰が ROLLBACK するのか？？ これを TRY...CATCH で自動化します。

SET XACT_ABORT ON;   -- 実行時エラーで自動的に ROLLBACK させる保険

BEGIN TRY
    BEGIN TRANSACTION;

    UPDATE dbo.Stock  SET Qty = Qty - 1    WHERE ProductId = 100;
    UPDATE dbo.Orders SET Status = 'Fixed' WHERE OrderId = 5001;

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;   -- 途中で落ちたら全部巻き戻す

    THROW;   -- エラーは握りつぶさず、呼び出し元へ再送出する
END CATCH;

実行結果（CATCH 内でわざとエラーを起こすと、更新が元の値に巻き戻る・SQL Server 2019 互換エンジンで確認）:

処理の流れを図にするとこんな感じ。

ポイントは2つあります。

ひとつ目、SET XACT_ABORT ON。これは「実行時エラーが出たら、その時点でトランザクションを強制的に中断扱いにする」スイッチです。

入れておかないと、エラーの種類によってはトランザクションが中途半端に生き残ることがある。バッチ系では原則 ON にしとくのが安全です。

ふたつ目、CATCH の中の IF @@TRANCOUNT > 0。@@TRANCOUNT は今開いているトランザクションの数。

これを見てから ROLLBACK しないと、「もう巻き戻し済みなのに、さらに ROLLBACK しようとしてエラー」みたいな二次災害が起きます。

THROW で再送出してるのは、エラーをアプリ側のログにちゃんと届けるため。ここを握りつぶすと、「失敗したのに成功したように見える」一番こわいパターンになります。

ハマりポイント: ROLLBACK 漏れで接続が開きっぱなしになる

ここ、俺がいっちばん痛い目を見たやつです。

TRY...CATCH を使わずに BEGIN TRANSACTION だけ書いて、途中で例外が飛ぶ。すると COMMIT も ROLLBACK もされないまま処理が抜けます。

-- ❌ ROLLBACK 漏れの典型
BEGIN TRANSACTION;
UPDATE dbo.Stock SET Qty = Qty - 1 WHERE ProductId = 100;
-- ここで例外 → COMMIT も ROLLBACK もされず、抜けてしまう
COMMIT TRANSACTION;

何が起きるか。開きっぱなしのトランザクションが、対象の行にロックを掛けたまま居座るんです。

別のセッションが同じ行を触ろうとすると、ロック待ちでひたすら止まる。

最悪、接続プールが詰まって画面全体が固まる。で、原因が「どこかで開いたまま放置されたトランザクション」だと気付くまでに、また時間が溶ける。

対策はシンプルで、BEGIN TRANSACTION を書いたら、必ず TRY...CATCH とセットにする。さっきのテンプレを雛形として持っておけば、これは踏みません！！

開きっぱなしを疑うときは、DBCC OPENTRAN で「一番古い未コミットのトランザクション」を確認できます。障害対応中はこれが効きます。

分離レベルの選び方 — 4種を業務SE視点で

ここまでが「書き込み側」の話。最後に「読み取り側」、分離レベルの話をします。

分離レベルは、「コミットされてないデータをどこまで見せるか / 読んでる間どこまでロックするか」 のさじ加減です。SQL Server の既定は READ COMMITTED。

業務でよく出る4種を、業務SEの判断軸で並べました。

ざっくり指針はこんな感じです。

• READ COMMITTED: 既定。大半の業務処理はこれでいい。迷ったらここから動かさない
• REPEATABLE READ: 同じトランザクション内で同じ行を2回読んだら必ず同じ値、を保証したい集計系
• SERIALIZABLE: 一番厳密。ただしロックを大量に持つのでデッドロックが起きやすい。安易に上げない
• SNAPSHOT: 読み取りがロックを待たない（行のバージョンを別に持つ方式）。参照の多い画面で書き込みとぶつかりたくない時に効く

設定はこう書きます。

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;   -- 既定
-- SET TRANSACTION ISOLATION LEVEL SNAPSHOT;       -- 読み取りがロックを待たない方式に