SQL UPDATE文の基本と安全な使い方｜事故を防ぐ実務ルールとDB別注意点

SQLのUPDATE文は、既存データを書き換えるという点で、INSERTやSELECTとは次元の違うリスクを持つSQLです。

WHERE句を書き忘れて全件更新
JOIN条件のミスで想定外の多重更新
NULLや型変換の罠で静かにデータ破壊

こうした事故は、初心者だけでなく実務経験者でも起こします。
なぜなら、UPDATEは「構文が簡単」なのに「影響範囲が極端に広い」からです。

この記事では、

UPDATE文の基本構文
実務で必須となる計算・CASE・別テーブル参照
DBごとの書き方の違い
本番事故を防ぐための実践手順・アンチパターン

までを体系的に解説します。

「UPDATEを安全に説明できる状態になる」ことが、この記事のゴールです。

UPDATE文とは何か──INSERT・DELETEとの決定的な違い

UPDATEは「行を増やさず、中身だけを書き換えるSQL」

UPDATE文は、すでに存在するレコードの列値を変更（上書き）するSQLです。

INSERT：行を追加する
DELETE：行を削除する
UPDATE：同じ行の中身だけを変える

主キーは変わらず、中身だけが差し替わるイメージです。

なぜUPDATEは事故が起きやすいのか

UPDATEの本質的な難しさは、

どの行が対象になるか
何行に影響するか

を、実行前に正確に把握する必要がある点にあります。

「どの行が、なぜ更新されるのか」を
人に説明できないUPDATEは、実行してはいけません。

UPDATE文の基本構文（UPDATE / SET / WHERE）

UPDATE文の基本形

UPDATE テーブル名
SET 列名 = 値
WHERE 条件;

UPDATE：対象テーブル
SET：更新内容
WHERE：更新対象の絞り込み

⇒ WHEREがないUPDATEは、原則「全件更新」です。

SET句に書けるもの

SETの右辺には、以下が書けます。

固定値
列
計算式
関数

便利な反面、型変換・NULL混在による事故が起きやすいポイントでもあります。

WHERE句がUPDATEの「安全装置」になる

主キー・ユニークキーで絞るのが基本

UPDATEは原則として、

主キー
ユニークキー

で対象を絞ります。

WHERE user_id = 123;

これが最も安全で、レビューしやすいUPDATEです。

UPDATE前に必ずSELECTする理由

SELECT *
FROM users
WHERE user_id = 123;

件数は想定通りか
対象行は本当にこの行か

⇒ UPDATE前SELECTは、実務では必須手順です。

複数カラムを同時に更新する理由

原子的に更新するメリット

UPDATE orders
SET status = 'DONE',
updated_at = NOW()
WHERE order_id = 100;

状態だけ変わる
更新日時が残らない

といった不整合を防止できます。

実務ルールとして決めておきたいこと

更新理由に関係ない列は触らない
「ついで更新」をしない

IN句で複数行を安全に更新する

主キーINは比較的安全

WHERE order_id IN (1, 2, 3);

対象が明確
レビューしやすい

IDが多い場合の注意点

SQLが読みにくくなる
実行計画が不安定になる

⇒ 大量IDは
一時テーブル or 作業用テーブル + JOINが安全です。

WHEREなし全件UPDATEの正しい扱い方

全件UPDATEは「高リスク作業」

意図的に行う場合でも、必須条件があります。

事前バックアップ
トランザクション
更新件数の事前確認

性能・ロックへの影響

インデックス更新コスト
トランザクションログ肥大
長時間ロック

⇒ 業務時間帯での全件UPDATEは避けるのが原則です。

NULLと空文字の更新は別物

NULLと空文字の違い

NULL：値が存在しない
空文字：長さ0の文字列

NULLを扱うときの基本

WHERE column IS NULL;
SET column = NULL;

DBごとの違い（特にOracle）

Oracleでは

空文字 = NULL

として扱われる点に注意が必要です。

公式ドキュメント：https://docs.oracle.com/

計算結果で更新する（SET句の式）

よくある例

SET price_with_tax = price * 1.1;

注意点

整数除算による切り捨て
丸め誤差
NULL混在で結果がNULLになる

⇒ CAST / ROUND / COALESCE を意識的に使います。

文字列結合で更新する（DB方言差に注意）

DBごとの代表例

MySQL：CONCAT()
PostgreSQL / Oracle：||
SQL Server：+

NULL対策は必須

COALESCE(col, '')

を使わないと、結合結果がNULLになります。

CASE式で条件分岐更新する

CASEの基本用途

ステータス変換
ランク付け
フラグ更新

ELSEを書かない危険性

ELSEなし = 条件漏れ → NULL更新

⇒ 原則、ELSEは明示する。

別テーブルを参照してUPDATEする

JOIN更新とサブクエリ更新

JOIN：対応関係が見えやすい
サブクエリ：1行性が重要

一意性が最大のポイント

参照先が1行に定まるか
多対多になっていないか

⇒ UPDATE前にJOIN SELECTで検証

DB別 UPDATE構文の違い

MySQL

UPDATE t
JOIN other o ON ...
SET t.col = o.col
WHERE ...

PostgreSQL

UPDATE t
SET col = o.col
FROM other o
WHERE ...

SQL Server

UPDATE t
SET col = o.col
FROM t
JOIN other o ON ...

Oracle

相関サブクエリ
MERGE（UPSERT）

公式情報：

MySQL：https://dev.mysql.com/doc/
PostgreSQL：https://www.postgresql.org/docs/
SQL Server：https://learn.microsoft.com/sql/
Oracle：https://docs.oracle.com/

UPDATE前に必ずやる安全手順

同条件SELECTで対象確認
トランザクションで実行
更新件数（row count）確認

⇒ SQLの上手さより、手順が安全性を決める

UPDATEのアンチパターン

避けたい書き方

CASE詰め込みすぎ
主キー・インデックス列の安易な更新
読めない巨大UPDATE

⇒ 人がレビューできないSQLは危険

まとめ｜UPDATEを安全に扱えるエンジニアになるために

UPDATEは最も強力で危険なSQL
WHEREで対象を説明できることが最重要
JOIN・CASE・計算は一意性と可読性が命
事前SELECT・トランザクション・件数確認を習慣化する

技術を「安全に使いこなす」現場で、一緒に働きませんか

UPDATE文をここまで丁寧に理解しようとするあなたは、
「ただ動くSQL」ではなく「安全に運用できる設計」に価値を置くエンジニアです。

私たちは、

データの整合性
運用事故を防ぐ設計
レビュー文化を大切にするチーム

で、日々プロダクトを改善しています。

もし
「SQLやDBを武器に、ちゃんとした現場で成長したい」
と感じたなら、ぜひ私たちの採用情報ものぞいてみてください。

同じ目線でデータと向き合える仲間を、探しています。