「このデータをSQLで直して」と頼まれ、本番のUPDATEを実行する前に手を止めて段取りを確かめている一人運用の保守担当者
保守・改修約12分

本番データをSQLで直すときの安全手順｜バックアップと件数確認

「お客さまのこのデータ、間違ってるからSQLで直しておいて」。 そう頼まれて本番のDBに向かうとき、軽い作業のはずなのに、なぜか手が震えますよね。

UPDATE の WHERE を1つ書き忘れただけで、全件が同じ値に書き換わる。 DELETE の条件をミスすれば、消してはいけない行まで消える。 しかも本番は、画面の操作と違って「ひとつ前に戻る」ボタンがありません。

一人で保守運用をしていると、このデータ修正を相談する相手もいないまま、自分一人で実行ボタンを押すことになります。 だからこそ、度胸ではなく手順で守るのがいちばん安全です。この記事では、本番データをSQLで直すときに、事故を防ぎながら進める順番を一緒に整理します。考えなくても手が止まる仕組みを、先に作っておきましょう。

結論：本番データをSQLで直すときは、①バックアップを取る → ②SELECTで対象と件数を先に確認 → ③トランザクションで囲む → ④UPDATE/DELETEを実行して影響件数を照合 → ⑤件数が想定どおりならCOMMIT、違えばROLLBACKの順で進めます。いきなりUPDATEを打たず、「同じWHEREで先にSELECT COUNT(*)」を挟むだけで、事故の大半は防げます。

DBの種類（MySQL・PostgreSQL・その他）や権限、本番の運用ルールによって、できることは変わります。 この記事の手順は出発点として、自分の現場のルールと環境に置き換えて使ってください。会社で「本番への直接SQLは申請が必要」と決まっているなら、まずそのルールが最優先です。

なぜ本番のデータ修正は怖いのか

データ修正が画面操作より怖いのは、理由があります。ここを言葉にしておくと、手順の一つひとつが「なぜ必要か」で腑に落ちます。

つまり怖いのは、あなたの腕のせいではなく、「見えないまま、戻せない操作をする」という構造のせいです。 だったら、見えるようにして、戻せるようにすればいい。それが次の手順です。

安全に直す5つの手順（順番に）

バックアップ・件数確認・トランザクション・実行と照合・確定の順に、本番データ修正を安全に進める5段の手順図
上から順に。先に控えと件数で「見える・戻せる」を作ってから実行する

頼まれたデータ修正は、次の順番で進めます。 各ステップは「戻せる状態」と「見える状態」を先に作るためのものです。焦っているときほど、上から順に。

① まずバックアップ（控え）を取る

実行の前に、戻せる準備をします。これがあるだけで、心の余裕がまったく変わります。

例：CREATE TABLE backup_orders_0625 AS SELECT * FROM orders WHERE id IN (...);

退避テーブルやダンプが取れるならそれがベスト、取れないなら値をテキストに残す。どちらでもいいので、「戻せる控えがどこにあるか」を一言で言える状態にしてから、次へ進みます。

② 同じWHEREで、先にSELECTして件数を見る

ここが、この記事でいちばん伝えたい一手です。UPDATEやDELETEを打つ前に、まったく同じWHEREでSELECTする。

ここで出た件数が「直したい行数」と一致しているかを確かめます。 「1件直すはずが、COUNTが400件」なら、そのWHEREはどこかが緩すぎます。実行する前に気づけました。逆に0件なら、条件が厳しすぎるか、対象が違います。

この「先にSELECT」を挟むだけで、WHEREの書き間違いの大半は実行前に止められます。

なお、SETで書き換える列を、そのままWHEREの条件にも使う修正（例：status='pending'の行をstatus='done'に変える）では、実行後にWHERE条件に当たる行が変わるため、事前の件数と影響件数がズレて当然のことがあります。この場合は件数のズレ＝失敗とは限らないので、慌ててROLLBACKせず、別の見分け方（後述の④の再SELECTなど）で確かめましょう。

③ トランザクションで囲む

確認したWHEREで実行に移りますが、その前にトランザクションで囲んで「すぐ戻せる」状態にします。対応しているDBなら、これが安全弁になります。

START TRANSACTION;   -- PostgreSQLなら BEGIN;

-- ここで UPDATE / DELETE を実行する

-- 件数と結果を確認してから…
COMMIT;    -- 想定どおりなら確定
-- ROLLBACK;  -- 少しでもおかしければ取り消し

COMMITするまでは、ROLLBACKで元に戻せます。 「実行 → 確認 → 確定（または取り消し）」を一呼吸の中でできるのが、トランザクションの強みです。COMMITを打つ前は、まだ引き返せます。

ひとつだけ注意。稼働中の本番テーブルでは、トランザクションを開けている間ずっと対象行にロックがかかり続けます。確認に手間取ってトランザクションを長く開けっぱなしにすると、後続のアプリ処理やバッチを止めてしまうことがあります。だから、**②の件数確認（SELECT COUNT(*)）はトランザクションの外で先に済ませておき、トランザクションの中は「実行 → 影響件数の確認 → COMMIT/ROLLBACK」だけを手早く**通すのがコツです。確認は丁寧に、でも開けている時間は短く。

④ 実行して、影響件数を②と照合する

トランザクションの中で、本命のUPDATE／DELETEを実行します。実行したら、「何行に影響したか」を必ず確認します。

UPDATEなら、念のため直した行をもう一度SELECTして、値が期待どおりかも目で見ておくと万全です。

⑤ 件数が合っていればCOMMIT、不安なら必ずROLLBACK

最後の確定です。ここだけは、勢いで押さないようにします。

ROLLBACKは失敗ではありません。「気づいて戻せた」という成功です。 迷ったら戻す。直し直せばいいだけなので、確定を急ぐ理由はどこにもありません。

やってしまいがちな落とし穴

手順の合間で、つい起きやすいところも先に共有します。知っているだけで避けられます。

落とし穴はどれも、②の件数確認と③のトランザクションでほとんど受け止められます。

明日、いちばん小さく試せること

全部を一度に身につけなくて大丈夫です。次にデータ修正を頼まれたとき、ひとつだけ試してみてください。

  1. 直したい条件を決めたら、まず**そのWHEREで SELECT COUNT(*) を1回**打つ。
  2. 出た件数が「直したい行数」と合っているかを確かめる。
  3. 合っていたら、START TRANSACTION;（またはBEGIN;）と打ってからUPDATE／DELETEを実行する。
  4. 影響件数が②と一致したらCOMMIT;、少しでも違えばROLLBACK;。

この「先にCOUNT、トランザクションで囲む」の2つを足すだけで、本番データ修正の安心感はぐっと変わります。

「SQLでデータ修正」安全チェックリスト

実行ボタンを押す前に、これだけ確認できているかを見る項目です。コピーして、自分のメモに当ててみてください。全部に○が付かなくても大丈夫なように、必須と推奨の二段に分けてあります。

必須（ここだけは——最大事故の「本番取り違え」「戻せない」を防ぐ最低ライン）

推奨（時間と環境が許せば。やれるほど安心が増えます）

忙しい日は、まず必須の3点（接続先・控え・件数確認）だけでも大丈夫。これだけで「本番取り違え」と「戻せない」という最大の事故は止められます。推奨は、できるところから足していけば十分です。

よければ、こちらも

データ修正は、改修や障害対応とつながっています。「直す前に影響を見る」「直したあとに何かあっても落ち着く」型をセットで持っておくと、当日とても楽になります。

件数を確かめてトランザクションでデータ修正を終え、安心してCOMMITできたと前向きな表情を見せる保守運用の担当者

本番のデータ修正がこわいのは、見えないまま戻せない操作をするからでした。でも、先にSELECTで件数を見て、トランザクションで囲んでおけば、「見える」も「戻せる」も自分の手の中に入ります。 今日は次の修正で、SELECT COUNT(*)を1回挟むだけで十分です。その一手が、震える指を、落ち着いて押せる指に変えてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語