Db2 LUWで複数カラムを更新するときは、SETの代入をカンマで区切り、WHEREで行を限定します。代入の列数と、更新する行数は別の話です。

この記事の要点
DB2 で複数カラムを 1 つの UPDATE で同時更新する書き方 正: UPDATE t SET colA = val1, colB = val2 WHERE ...（カンマ区切り） 誤: UPDATE t SET colA = val1 AND colB = val2（複数の代入を並べる構文ではない） 基本のカンマ区切りが似ていても、他DBのJOIN UPDATE・日時関数・代入評価の規則を流用しない

 

本稿はDB2で複数カラムをupdateする方法を説明します。

SETに複数の代入を書くときは、次の元の例のようにカンマで区切ります。ANDはWHEREの条件を組み合わせる用途等と区別します。test_table、colA、val1、where ...は説明用の仮名/省略で、実行可能な完成SQLではありません。

UPDATE test_table SET colA = val1, colB = val2 where ...

 

値と条件を分けた複数列UPDATE

在庫の利用可能数AVAILABLEから予約数RESERVEDへ数量を移す例です。ITEM_IDが一意キー、両数量はNOT NULLの整数という前提です。下はアプリのPreparedStatement等で使うSQLで、?を残したままCLPへ貼りません。バインド順は「数量、同じ数量、商品ID、同じ数量」です。数量は呼出前に正の整数・列の範囲内と検証し、予約数の加算も上限を超えないよう業務制約を確認します。

UPDATE APP.INVENTORY
SET AVAILABLE = AVAILABLE - ?,
    RESERVED = RESERVED + ?
WHERE ITEM_ID = ?
  AND AVAILABLE >= ?;

SETのカンマは変更する列の区切り、WHEREのANDは対象条件です。AVAILABLEの条件も同じUPDATEに入れることで、別SELECTの確認値だけを信じた更新を避けます。ただし、このSQLだけで予約操作の重複受付や他の更新経路まで安全になるわけではありません。主キー/制約、他の処理が守るルール、分離レベル、デッドロック/タイムアウトも設計します。

更新件数1ならこの条件に合う1行を更新、0なら商品が存在しない/在庫条件に合わない等を区別して扱います。0件をSQL失敗とは限りません。1行を想定して複数行になった場合はキー/条件を疑い、勝手に成功扱いしません。件数取得方法は使うドライバー/APIに従い、トリガー等の副作用までその数だけで確認できたと扱わないでください。

右辺が参照するのは更新前の列値

Db2 LUWでは通常の列代入の右辺に書いた列参照は、その行が更新される前の値を使います。次の例で元のAが10なら、更新後はA=11、B=10です。先にAを変えたからBも11になる、という左から順の手続きとして読まないでください。Bにも新しい値を入れたいならBの式を別に設計します。構造化型の属性更新など、すべてのSQLへこの説明を無条件に広げません。

UPDATE APP.DEMO
SET A = A + 1,
    B = A
WHERE ID = ?;

実行前後の確認と再実行の注意

1. 接続先DB・正確なschema/表名、更新権限、列型/NULL/DEFAULT/制約、対象キーを確認する。名前を入力文字列からSQLへ直接つながない。?でバインドできるのは値で、表名/列名の代替ではない。
2. 同じ条件のSELECTで想定対象を確認する。ただし、その後の他接続の変更を防ぐ保証ではない。実行するUPDATE自身にも対象条件を残す。
3. 複数の文をまとめるなら、使用APIの自動コミット設定・確定/巻き戻しと失敗時の状態を確認する。SQLを複数行書いただけで全体が自動的に1transactionになるわけではない。
4. 更新件数と更新後の値を照合し、想定外なら確定前に処理を止めて巻き戻し方針を適用する。自動コミット済みの変更を後からROLLBACKできるとは限らない。
5. 加算/減算の再送は二重予約/二重減算を起こす。通信断やCOMMIT結果不明を含め、失敗した文だけを無条件に再試行しない。操作ID等による重複対策は業務側で別途設計する。

よくある間違い

• WHEREなしは原則すべての対象行への更新になる。全件更新が目的なら構文上可能だが、件数・負荷・復旧を事前確認する。
• NULLとの演算結果や小数の丸めを確認する。COALESCEで0に変えれば必ず正しいとは限らず、NULLの業務上の意味を先に決める。
• 複数行の更新順序をSETの列順や主キー順から推測しない。MySQLのUPDATE JOIN/DATE_SUB/ON DUPLICATE KEY等はこのDb2用の例ではない。
• 大量更新をただ分割すると、途中成功や再実行の境界が変わる。索引再構築・定期REORG・設定変更を全UPDATEに必須の処理としない。

関連ページ

カラムの追加/削除/変更は表定義のDDLで、行の値を変えるUPDATEとは別です。現在値に加算する方法、@Modifyingは元の関連リンクを保持しますが、対象製品/ORMを確認して参照してください。エラー時はDb2エラー一覧へ。

公式：Db2 LUW UPDATE / LUWの列参照/代入規則。

対象範囲と検証

主にDb2 LUWを対象とし、2026年10月に公式資料と照合しました。元のDb2版のコードと情報を回復し、別製品へ置換されていた版も履歴に保持しています。追加SQLの条件・順序等はメモリ内の合成データで確認しましたが、Db2実機の構文/権限/ロック/負荷・全構成での変更成功を検証したものではありません。Db2親ページの子ページから選択してください。