SQL ServerのUPDATE文の使い方【基本〜応用・実務で事故らない完全ガイド】

SQL ServerのUPDATE文は、日常業務で最も頻繁に使われる一方、最も事故が起きやすいSQLです。
「WHERE句を書き忘れて全件更新してしまった」「JOIN更新で想定外の行が書き換わった」「本番でロックがかかりサービスが止まった」——こうしたトラブルは、決して珍しくありません。

この記事では、

• UPDATE文の正しい基本構文
• CASE式・JOIN更新などの実務で必須の応用パターン
• 制約・インデックス・ロック・ログといった運用視点の注意点
• 事故を未然に防ぐための安全な実行手順
• 現場でよく見るアンチパターンと改善策

までを、初心者にも分かりやすく、かつ実務経験者が納得できる深さで体系的に解説します。

「UPDATEを“書ける”から“安全に使いこなせる”レベルへ」
この記事が、その一段階上に進むための指針になれば幸いです。

UPDATE文とは｜役割とINSERT・DELETEとの違い

UPDATEの役割

UPDATE文は、すでに存在する行の値を変更するSQLです。

• 顧客のメールアドレス変更
• 商品価格の改定
• ステータスフラグの一括更新

など、「行はそのまま・中身だけ変える」場面で使います。

UPDATEは行数を増減させません。しかしその代わり、ロック・トランザクションログ・制約など、周辺への影響が非常に大きい操作です。

UPDATEでできること／できないこと

できること

• 既存行の列値を変更する
• 複数列を同時に更新する
• 条件に応じて値を変える（CASE式）
• 他テーブルの値を参照して更新する（UPDATE FROM）

できないこと・注意点

• 行の追加（INSERTが担当）
• 行の削除（DELETEが担当）
• 更新不可なVIEWへの更新
  
  （集約・DISTINCT・キー欠落があるVIEWは不可な場合が多い）

また、トリガーが設定されているテーブルでは、UPDATEをきっかけに別処理が動く点にも注意が必要です。

UPDATEが影響する範囲｜行・ロック・トランザクションログ

UPDATEは単なる値変更ではありません。

• WHERE句で指定した行がロックされる
• 更新内容がトランザクションログに記録される
• インデックスも更新対象になる

特に大量更新では、

• ログ肥大化
• ブロッキング
• レプリケーション／可用性構成への影響

が顕在化します。
UPDATEは「書き換え」ではなく、重いI/O操作だと理解しておくことが重要です。

UPDATE文の基本構文

最小構成（UPDATE / SET / WHERE）

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

例：

UPDATE Employees SET Email = 'new@example.com' WHERE EmployeeID = 10;

WHERE句がなければ全件更新実務では
「WHEREは必須」と考えてください。

実務の定石｜いきなりUPDATEしない

安全な流れは次の通りです。

1. 同じWHERE条件でSELECT

2. 対象件数・内容を確認

3. UPDATEを実行

SELECT * 
FROM Employees 
WHERE EmployeeID = 10;

この一手間が、事故の大半を防ぎます。

SET句の評価順と注意点

複数列更新の落とし穴

UPDATE Sample 
SET Col2 = Col1, 
    Col1 = 0;

SET内では更新前の値が参照されると考えるのが安全ですが、読み手に誤解を与えやすい書き方です。

• 中間値をサブクエリで明示
• CROSS APPLYを使う
• 変数に退避する

など、「意図が一意に伝わる書き方」を選びましょう。

更新件数の確認｜@@ROWCOUNT

UPDATE ... 
SELECT @@ROWCOUNT;

• 0件 → 条件ミス・対象なし
• 想定以上 → 誤更新の可能性

バッチ処理では、件数チェックをガード条件にするのが実務では定番です。

WHERE句で事故を防ぐ

主キーで1行を更新する（最も安全）

WHERE EmployeeID = 100

• 一意に決まる
• 将来も複数行にならない

これがUPDATE条件の理想形です。

複合条件（AND / OR）の注意点

WHERE Status = 'A' 
  AND (Type = 'X' OR Type = 'Y')

• ORは必ず括弧で明示
• NULL判定は IS NULL / IS NOT NULL
• 列に関数をかけるとインデックスが効きにくい

IN句で複数行を更新する

WHERE ProductID IN (101, 105, 120)

• 対象が明確なときに有効
• 実行前に必ずSELECTで確認

サブクエリINも可能ですが、件数が多い場合はJOINの方が最適化されやすいこともあります。

WHEREなし全件更新の危険性

全件更新が許されるケース

• フラグの初期化
• 年度切替処理
• ロジック変更後の再計算

それでも必須なのは、

• 事前SELECTで影響範囲確認
• 実行時間帯の検討
• バックアップ／ロールバック手段の確保

「本当に全件でなければならないか？」を必ず疑うのがプロの判断です。

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

UPDATE Employees 
SET DepartmentID = 3, 
    UpdatedAt = GETDATE() 
WHERE EmployeeID = 10;

注意点

• 同値更新を避ける
• 更新列は必要最小限に
• トリガー／CDCへの影響を意識

計算結果で更新する

算術演算（増減・丸め）

SET Price = ROUND(Price * 1.1, 0)

• データ型（int / decimal）に注意
• 金額計算は丸め規則を明示

NULL対策

SET Total = Salary + COALESCE(Bonus, 0)

NULLを0扱いしてよいかは業務仕様次第です。

文字列連結で更新する

+ と CONCAT の違い

SET FullName = CONCAT(LastName, ' ', FirstName)

CASE式で条件分岐更新

SET Rank = 
  CASE 
    WHEN Score >= 90 THEN 'A' 
    WHEN Score >= 70 THEN 'B' 
    ELSE 'C'
  END

• ELSEは原則必須
• 巨大CASEは可読性・保守性が低下

別テーブルの値で更新する（UPDATE FROM）

基本形

UPDATE e 
SET e.DepartmentID = d.DepartmentID 
FROM Employees e 
JOIN Departments d 
  ON e.DeptCode = d.DeptCode;

最大の注意点

• JOIN先が1行に一意に決まること
• 1対多は事故の温床

必要なら、

• 集約
• ROW_NUMBERで代表行選択
• ユニーク制約追加

で担保します。

主キー・インデックスとUPDATE

• インデックス列更新＝追加コスト
• 主キー更新＝参照整合性崩壊リスク

更新頻度の高い列はキーにしない
これは設計段階での重要な判断です。

制約違反を防ぐための事前チェック

• PK / UNIQUE → 重複しないか
• FK → 参照先が存在するか
• NOT NULL / CHECK → NULLや範囲外が入らないか

更新式をそのままSELECTに写して事前検証するのが鉄板です。

UPDATE前の安全手順（実務テンプレ）

1. 同じWHEREでSELECT

2. BEGIN TRAN

3. UPDATE実行

4. 結果確認

5. COMMIT or ROLLBACK

BEGIN TRAN; 

UPDATE ... 

SELECT @@ROWCOUNT; 

-- 問題なければ 
COMMIT; 
-- NGなら 
ROLLBACK;

UPDATEでよくあるアンチパターン

• WHEREなしUPDATE
• OR条件の括弧漏れ
• 巨大CASEで業務ロジック詰め込み
• キー列の安易な更新

「動いた」より「説明できる・保守できる」SQLを目指しましょう。

UPDATEが遅いときの切り分け

• 実行計画（スキャンかシークか）
• ロック／ブロッキング
• 更新件数の規模

大量更新は、

• 分割更新（TOP）
• 実行時間帯調整
• 後処理（インデックス再編成）

まで含めて設計します。

まとめ｜UPDATEは「書き方」より「使い方」が9割

• UPDATEは強力だが危険
• WHERE設計が事故防止の要
• 実行前確認と手順化が品質を決める
• パフォーマンス・制約・運用まで含めて考えるのがプロ

SQL ServerのUPDATE文を正しく理解することは、
データを守り、サービスを守るエンジニアリングそのものです。

技術を深く理解し、現場で活かしたいあなたへ

ここまで読んで「UPDATEって奥が深い」「設計や運用まで含めて考えるのが面白い」と感じた方は、
きっとデータベースやバックエンドを本気で扱う仕事に向いています。

私たちは、

• SQL Serverを含むRDBを軸に
• 安全性・性能・保守性を重視した設計を行い
• 現場で“本当に使える”技術を大切にするチームです。

もし、
「もっと良いSQLを書きたい」
「データと真剣に向き合う仕事がしたい」
そう感じたなら、ぜひ一度、私たちの採用情報を覗いてみてください。

同じ目線で技術を語り、成長していける仲間を、私たちは探しています。