MySQLで複数行をまとめてUPDATEする方法を徹底解説！

はい、承知いたしました。MySQLで複数行をまとめてUPDATEする方法について、詳細な解説を含む約5000語の記事を記述します。

MySQLで複数行をまとめてUPDATEする方法を徹底解説！パフォーマンス、安全性、シナリオ別アプローチ

はじめに

データベース管理システム（DBMS）において、データの更新は最も基本的な操作の一つです。単一の行を更新することは比較的簡単ですが、実世界のアプリケーションでは、しばしば大量のデータを一度に、あるいは特定の条件に基づいてまとめて更新する必要があります。このような「複数行をまとめてUPDATEする」操作は、データベースの効率性、パフォーマンス、および整合性を維持する上で極めて重要です。

例えば、

セール期間終了後、特定カテゴリーの全商品の価格を元に戻す
システム連携により、外部データに基づき顧客のステータスを一括で変更する
バッチ処理で、特定の条件を満たすレコードのフラグを立てる
不正アクセス対策として、疑わしいIPアドレスからのログイン試行を記録した複数レコードに警告フラグを付与する

といったシナリオでは、複数行のUPDATEが不可欠となります。

もしこれらの操作を1行ずつ逐次的に実行した場合、どのような問題が発生するでしょうか？

パフォーマンスの低下: データベースへの接続・切断、SQL解析、トランザクション開始・終了といったオーバーヘッドが各行ごとに発生し、処理時間が膨大になります。
リソースの浪費: ネットワークトラフィックが増加し、データベースサーバーへの負荷も高まります。
データの不整合のリスク: 複数行を個別のトランザクションで更新した場合、途中で処理が中断されると、一部の行だけが更新され、データに不整合が生じる可能性があります。

これらの問題を回避し、効率的かつ安全に複数行を更新するために、MySQLはさまざまな方法を提供しています。この記事では、MySQLで複数行をまとめてUPDATEする代表的な方法を網羅し、それぞれの構文、メリット・デメリット、具体的な使用例、そして大規模なUPDATE操作におけるパフォーマンス最適化と注意点について、徹底的に解説します。

この記事を読むことで、あなたは以下のことを習得できます。

最も基本的な一括UPDATEの方法
行ごとに異なる値を更新するための高度な方法（CASE文、JOIN、VALUES関数、一時テーブル）
それぞれの方法がどのようなシナリオに適しているか
大規模なUPDATE操作を実行する際のパフォーマンス課題と解決策（トランザクション、ロック、インデックス、バッチ処理など）
安全にUPDATEを実行するためのベストプラクティス

データベースの効率的な運用を目指すすべての方、特に開発者、データベース管理者（DBA）、およびデータエンジニアにとって、この記事は実践的な知識を提供します。さあ、MySQLでの複数行UPDATEの世界を深く探求していきましょう。

なぜ複数行UPDATEが必要か？1行ずつ更新する際の隠れたコスト

先にも触れましたが、複数行をまとめてUPDATEする重要性を理解するためには、その対極にある「1行ずつUPDATEする」方法が抱える問題点を深く掘り下げることが有益です。

仮に、更新対象が1000件あるとします。これを1行ずつUPDATEするということは、以下のような処理を1000回繰り返すことを意味します。

アプリケーションからデータベースへの接続確立（または既存接続の利用）
SQLステートメント（UPDATE ... WHERE id = X）の準備と送信
データベースサーバーでのSQLの解析、実行計画の生成
対象行の検索（通常は主キー検索）
行ロックの取得
データの更新（メモリ上、undoログへの記録）
インデックスの更新
バイナリログへの記録（レプリケーション有効時）
行ロックの解放
トランザクションのコミット（または各UPDATE文が自身のトランザクション）
結果のアプリケーションへの返送
データベース接続の解放（または次の処理のための維持）

このシーケンスを1000回繰り返すのです。問題点は明らかです。

ネットワークラウンドトリップの増大: アプリケーションとデータベースサーバー間の通信が1000回発生します。ネットワーク遅延が大きければ大きいほど、全体の処理時間は長くなります。
データベースサーバーのリソース消費: SQL解析、実行計画生成、トランザクション管理、ロック管理といったCPU集約的な処理が1000回発生します。これはサーバーのリソース（CPU、メモリ）を圧迫します。
トランザクションオーバーヘッド: 各UPDATE文を個別のトランザクションとして実行した場合、コミット処理のオーバーヘッドが1000回発生します。もし1つの大きなトランザクション内で1000回のUPDATEを実行した場合でも、ロックが長時間保持されるリスクや、中間状態での障害からのリカバリの複雑さが増します。
ロック競合の可能性: 1行ごとのロックは比較的短時間ですが、多くのクライアントが同時に異なる行を更新しようとした場合、ロック待ちが発生しやすくなります。また、同じテーブルに対する他の操作（SELECTやINSERT）も影響を受ける可能性があります。
バイナリログの肥大化: ROWフォーマットのバイナリログを使用している場合、1000回のUPDATEは1000件分の更新前後の行イメージをログに記録することになり、ログファイルが急速に肥大化する可能性があります。これはレプリケーション遅延の原因にもなり得ます。

一方、複数行をまとめてUPDATEする場合、通常は1つのSQLステートメントとして処理されます。

アプリケーションからデータベースへの接続確立
SQLステートメント（UPDATE ... WHERE ... またはより複雑なステートメント）の準備と送信
データベースサーバーでのSQLの解析、実行計画の生成
対象行の検索（条件に合致する複数行）
対象行に対する適切なロックの取得
データの更新（メモリ上、undoログへの記録）
インデックスの更新
バイナリログへの記録
ロックの解放
トランザクションのコミット（通常、1つのステートメントは1つのトランザクションとして扱われるか、明示的なトランザクション内で実行）
結果のアプリケーションへの返送

この場合、オーバーヘッドの多くは1回、または数回で済みます。

ネットワークラウンドトリップの削減: 1回または数回の通信で済みます。
データベースサーバーのリソース効率向上: SQL解析や実行計画生成は1回です。ロック管理も複数の行に対してまとめて行われる場合があります。
トランザクションの効率化: 1つの大きなトランザクションとして、あるいはステートメントレベルでのアトミック性によって、まとめて処理が完了します。これにより、データの一貫性が保たれやすくなります。
ロック管理の効率化: データベースシステムは、複数行に対する更新ロックを効率的に管理できます。ただし、ロックの粒度や保持期間には注意が必要です。
バイナリログの最適化: ステートメントベースのバイナリログでは、1つのSQLステートメントだけが記録されます。ROWベースでも、複数行に対する1回の更新として内部的に効率化される場合があります。

このように、複数行をまとめてUPDATEすることは、パフォーマンス、リソース効率、データ整合性の観点から、ほとんどの場合で1行ずつ更新するよりも優れています。

基本的な複数行UPDATEの方法: `UPDATE ... WHERE ...`

最も一般的で基本的な複数行UPDATEの方法は、UPDATE ステートメントに WHERE 句を組み合わせて、特定の条件に一致するすべての行を一括で同じ値に更新するものです。

構文:

sql UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition;

table_name: 更新対象のテーブル名。
SET: 更新するカラムとその新しい値を指定します。複数のカラムを更新する場合は、カンマで区切ります。
column1 = value1: column1 というカラムを value1 という値に更新します。value1 にはリテラル値、カラム名、式、またはサブクエリの結果を指定できます。
WHERE condition: 更新対象の行を指定するための条件です。この条件に一致するすべての行が更新されます。WHERE 句を省略すると、テーブル内のすべての行が更新されるため、非常に危険です。必ず WHERE 句を指定し、更新対象を限定するようにしてください。

簡単な例:

例えば、products テーブルがあり、category が ‘Electronics’ のすべての商品の status を ‘Discontinued’ に変更したいとします。

sql UPDATE products SET status = 'Discontinued' WHERE category = 'Electronics';

このステートメントを実行すると、products テーブルの中で category カラムの値が ‘Electronics’ であるすべての行が検索され、それぞれの行の status カラムが ‘Discontinued’ に更新されます。

別の例として、在庫数が0以下の商品の is_available フラグを FALSE に設定する場合。

sql UPDATE products SET is_available = FALSE, last_updated = NOW() -- 複数のカラムを同時に更新 WHERE stock_quantity <= 0;

この方法は、特定の条件を満たす複数行に対して同じ値を設定したい場合に最もシンプルで効率的です。内部的には、MySQLは WHERE 句の条件を満たす行を特定し、それらの行に対してまとめて更新処理を実行します。

メリット:

構文がシンプルで分かりやすい。
特定の条件に一致する行を一括で同じ値に更新する最も標準的な方法。
通常、パフォーマンスは良好（特に WHERE 句でインデックスが効率的に使用される場合）。

デメリット:

更新対象の全行に対して、同じ値を設定することしかできない。行ごとに異なる値を設定するには、後述の別の方法が必要。
WHERE 句の条件が適切でない場合、意図しない行まで更新してしまうリスクがある。
WHERE 句が複雑であったり、適切なインデックスがない場合、フルテーブルスキャンが発生し、パフォーマンスが低下する可能性がある。

この基本的な方法は、複数行UPDATEの出発点となります。しかし、実務では「この条件を満たす行はAという値に、別の条件を満たす行はBという値に更新したい」「別のテーブルの情報に基づいて更新したい」といった、より複雑な要件が出てきます。次に、これらの高度なシナリオに対応する方法を見ていきましょう。

行ごとに異なる値をUPDATEする方法

ここからは、更新対象の行ごとに異なる値を設定する必要があるシナリオに対応するための方法を解説します。これは複数行UPDATEの中でも特に柔軟性が求められるケースです。

1. CASE文を使った方法

UPDATE ステートメントの SET 句内で CASE 文を使用することで、WHERE 句で絞り込まれた行の中でも、さらに細かな条件に応じて更新する値を動的に決定できます。これは、特定のカラムの値や、他のカラムの値に基づいて、更新するカラムの値を変更したい場合に非常に便利です。

構文:

sql UPDATE table_name SET column_to_update = CASE WHEN condition1 THEN value1 WHEN condition2 THEN value2 ... ELSE default_value -- オプション END, another_column = another_value -- 他のカラムも同時に更新可能 WHERE main_condition; -- 更新対象の全体的な条件

column_to_update: 値を変更したいカラム名。
CASE ... END: CASE 式全体が、column_to_update に設定される新しい値となります。
WHEN condition THEN value: condition が真の場合に value が使用されます。複数の WHEN 句を記述できます。MySQLは上から順に評価し、最初に一致した WHEN 句の value を採用します。
ELSE default_value: オプションです。どの WHEN 句の条件も一致しない場合に default_value が使用されます。ELSE が省略され、どの WHEN にも一致しない場合、その行の column_to_update は変更されません（ただし、WHERE 句で対象とされた行に限る）。
main_condition: WHERE 句で指定する、UPDATEの対象となる行の全体的な条件です。CASE 文は、この main_condition を満たす行に対してのみ評価・実行されます。

具体的な例:

顧客テーブル customers があり、購入金額 total_purchase_amount に応じて顧客ランク customer_rank を更新したいとします。

購入金額が10000以上: ‘Premium’
購入金額が5000以上10000未満: ‘Gold’
購入金額が5000未満: ‘Silver’

sql UPDATE customers SET customer_rank = CASE WHEN total_purchase_amount >= 10000 THEN 'Premium' WHEN total_purchase_amount >= 5000 THEN 'Gold' ELSE 'Silver' END, last_rank_update = NOW() -- ランク更新日時も同時に記録 WHERE -- 必要に応じて、特定の条件で絞り込むことも可能（例: 最終購入日から1年以上経過していない顧客など） 1=1; -- この例では全顧客を対象とします

このクエリは、customers テーブルの全行（WHERE 1=1 のため）に対して CASE 文を評価し、total_purchase_amount の値に応じて customer_rank を設定します。同時に last_rank_update も現在時刻に更新します。

別の例として、特定のIDリストに基づいて、それぞれのIDに対応するステータス値を設定したい場合。

仮に、ID 101はステータス ‘Active’、ID 105はステータス ‘Suspended’、ID 112はステータス ‘Pending’ にしたいとします。

sql UPDATE users SET status = CASE id WHEN 101 THEN 'Active' WHEN 105 THEN 'Suspended' WHEN 112 THEN 'Pending' ELSE status -- リストに含まれないIDはステータスを変更しない END WHERE id IN (101, 105, 112); -- 更新対象をIDリストに絞り込む

この例では、CASE 文の後にカラム名 (id) を指定する形式を使用しています。これは、特定のカラムの値に基づいて条件を分岐させる場合に有効です。WHERE id IN (...) 句で更新対象を絞り込んでいるため、リストに含まれないIDの行はそもそもUPDATEの対象になりません。ただし、CASE 文内に ELSE status を含めることで、万が一 WHERE 句を忘れた場合でも、リストに含まれないIDのステータスが意図せず変更されることを防ぐセーフティネットになります。

メリット:

同じ UPDATE ステートメント内で、行ごとに異なる値を柔軟に設定できる。
条件分岐ロジックをSQL内に記述できるため、アプリケーション側のコードがシンプルになる場合がある。
比較的読みやすい構文。

デメリット:

CASE 文内の条件が多い場合、ステートメントが長くなり、可読性が低下する可能性がある。
更新対象の行数が非常に多い場合、CASE 文の評価に時間がかかり、パフォーマンスに影響を与える可能性がある。
設定したい値が、更新対象のテーブル以外のテーブルのデータに依存する場合、この方法単独では対応できない（JOINが必要になる）。

CASE 文を使った方法は、更新する値が、更新対象テーブル内の既存の値や、特定の固定値のリストに基づいて決定される場合に非常に強力です。

2. JOINを使った方法

UPDATE ステートメントは、他のテーブルと結合（JOIN）して、結合したテーブルのデータに基づいて更新対象テーブルの行を更新することができます。これは、別のテーブルに格納されている情報を使って現在のテーブルのデータを最新の状態に保ちたい場合や、複雑なリレーションシップに基づいた更新を行いたい場合に必須となる方法です。

構文:

sql UPDATE table_to_update JOIN table_to_join ON join_condition SET table_to_update.column1 = table_to_join.columnA, table_to_update.column2 = expression_using_joined_data, ... WHERE condition_using_joined_data; -- オプション

UPDATE table_to_update: 更新対象のテーブルを指定します。
JOIN table_to_join ON join_condition: 更新対象テーブルと結合するテーブルを指定し、結合条件を ON 句で記述します。INNER JOIN, LEFT JOIN など、通常のJOIN構文が使用できます。
SET: 更新するカラムとその値を指定します。ここで、結合したテーブル (table_to_join) のカラムや、結合した両方のテーブルのカラムを使った式を、更新する値として指定できます。カラム名の衝突を避けるために、テーブルエイリアスやテーブル名をプレフィックスとして付けるのが一般的です。
WHERE condition_using_joined_data: オプションですが、指定した結合条件に加えて、さらに更新対象を絞り込む条件を記述できます。結合したテーブルのカラムを使った条件も指定可能です。

具体的な例:

注文テーブル orders と顧客テーブル customers があり、orders テーブルの最新の購入日 order_date を基に、customers テーブルの last_purchase_date カラムを更新したいとします。

まず、各顧客の最新の注文日を取得する必要があります。これはサブクエリやJOINを使って事前に計算できます。ここでは、直接JOINを使ってUPDATEします。

sql UPDATE customers c -- customers テーブルを c というエイリアスで参照 JOIN ( SELECT customer_id, MAX(order_date) AS latest_order_date FROM orders GROUP BY customer_id ) AS latest_orders ON c.customer_id = latest_orders.customer_id SET c.last_purchase_date = latest_orders.latest_order_date, c.is_active_customer = TRUE -- 最新の注文があった顧客をアクティブにマーク WHERE c.last_purchase_date IS NULL OR c.last_purchase_date < latest_orders.latest_order_date; -- customers テーブルの既存の last_purchase_date がNULLの場合、または -- 新しい最新注文日よりも古い場合に更新

この例では、サブクエリで各顧客の最新注文日を計算し、その結果セットを latest_orders という一時的なテーブルのように扱っています。そして、customers テーブル (c) と latest_orders を customer_id で結合し、結合結果に基づいて c.last_purchase_date と c.is_active_customer を更新しています。WHERE 句は、既に最新の日付が記録されている顧客や、最新注文日がない顧客（サブクエリの結果セットに含まれない）を更新対象から除外するために使用しています。

別の例として、商品テーブル products と在庫更新情報テーブル stock_updates があり、stock_updates に基づいて products の在庫数 stock_quantity を更新したい場合。

“`sql
— stock_updates テーブルには product_id と新しい在庫数 new_quantity が格納されているとする
— 例: INSERT INTO stock_updates (product_id, new_quantity) VALUES (101, 50), (105, 0), (112, 25);

UPDATE products p
JOIN stock_updates su ON p.product_id = su.product_id
SET
p.stock_quantity = su.new_quantity,
p.last_stock_update = NOW();
— WHERE句で特定の更新に絞ることも可能
“`

このクエリは、products テーブルと stock_updates テーブルを product_id で結合し、stock_updates に存在する商品IDに対応する products テーブルの行の在庫数を、stock_updates の new_quantity の値で更新します。

JOINを使ったUPDATEの注意点:

結合条件 (ON 句) は正確に記述する必要があります。誤った結合は意図しない更新やエラーを引き起こします。
もしJOIN結果に更新対象の table_to_update の同じ行が複数回出現する場合（例: 1対多の結合で多の側のテーブルに同じキーを持つレコードが複数ある）、MySQLはどの行を更新に使うか不定になります。このような状況を避けるため、サブクエリやGROUP BYを使って、更新に使うデータを行意的に一意に絞り込む必要があります（上記の最初の例のように）。
JOINするテーブルが多い場合や、結合条件が複雑な場合、クエリのパフォーマンスに影響が出る可能性があります。適切なインデックスがJOIN条件のカラムに存在することが非常に重要です。

メリット:

別のテーブルの情報に基づいて、複数行の値を柔軟に更新できる。
複雑なデータリレーションシップに基づいた更新処理を、SQL内で完結できる。
サブクエリを使用するよりも読みやすい場合がある。

デメリット:

JOIN条件や更新ロジックが複雑になりがち。
JOIN結果に重複行がある場合の挙動に注意が必要。
パフォーマンスはJOINの効率に依存するため、インデックスやデータ構造の設計が重要。

JOINを使ったUPDATEは非常に強力ですが、その複雑さゆえに、クエリの設計とテストには慎重さが求められます。特に大規模データに対する実行前には、少量のデータで十分にテストすることをお勧めします。

3. VALUES() 関数を使った方法 (INSERT … ON DUPLICATE KEY UPDATE の応用)

この方法は厳密には UPDATE ステートメントそのものではありませんが、複数行の新しいデータをバッチで投入する際に、もし同じ主キーやユニークキーを持つ行が既に存在していればその行を更新する、という処理を効率的に行うための強力な手段です。特に、外部ファイル（CSVなど）からデータをインポートする際や、バッチ処理でデータを集計・整形してテーブルに反映させる際に威力を発揮します。

使用するのは INSERT ... ON DUPLICATE KEY UPDATE 構文です。

構文:

sql INSERT INTO table_name (column1, column2, ..., unique_key_column) VALUES (value1_row1, value2_row1, ..., unique_key_value_row1), (value1_row2, value2_row2, ..., unique_key_value_row2), ... ON DUPLICATE KEY UPDATE column1 = value_to_update_col1, column2 = value_to_update_col2, ...;

INSERT INTO table_name (...) VALUES (...), (...): 通常の複数行INSERT構文です。ここで指定するデータは、挿入または更新したい新しいデータのセットです。
ON DUPLICATE KEY UPDATE: INSERT しようとした際に、指定したカラム（unique_key_column）が、テーブルの PRIMARY KEY または UNIQUE KEY 制約に違反した場合（つまり、同じキーを持つ行が既に存在する場合）に実行される処理を定義します。
column1 = value_to_update_col1: 重複キーが見つかった場合に更新されるカラムとその新しい値を指定します。ここで新しい行の値を参照するために VALUES(column_name) 関数を使用できます。

VALUES(column_name) 関数は、ON DUPLICATE KEY UPDATE 句の中でだけ使用でき、INSERT 句で指定された、重複キーが検出された現在の行の、指定された column_name に対応する値を返します。

具体的な例:

商品在庫数 products テーブルがあり、外部から新しい在庫データ new_stock_data を受け取ったとします。new_stock_data には product_id と new_quantity が含まれています。このデータを使って、products テーブルの在庫数を更新したいのですが、もし new_stock_data に新しい商品が含まれていたら、その商品は新規に挿入したいとします。

products テーブルには product_id が PRIMARY KEY または UNIQUE KEY として設定されている必要があります。

“`sql
— 例として、更新または挿入したいデータが以下のように生成されたとする
— (101, 50), (105, 0), (201, 100) — product_id 201 は新規商品

INSERT INTO products (product_id, stock_quantity, last_stock_update)
VALUES
(101, 50, NOW()),
(105, 0, NOW()),
(201, 100, NOW()) — 新規の product_id
ON DUPLICATE KEY UPDATE
— product_id が重複した場合、既存の行を更新する
stock_quantity = VALUES(stock_quantity), — INSERTで指定した新しい stock_quantity の値を使用
last_stock_update = VALUES(last_stock_update); — INSERTで指定した新しい last_stock_update の値を使用
“`

このクエリは、VALUES 句で指定された3行のデータを処理します。

product_id が101と105の行は products テーブルに既に存在するため、ON DUPLICATE KEY UPDATE 句が実行されます。既存の行の stock_quantity が挿入データ (VALUES(stock_quantity)) の値（それぞれ50と0）に更新され、last_stock_update も更新されます。
product_id が201の行は products テーブルに存在しないため、新規に挿入されます。

この方法の重要な利点は、挿入と更新の処理を1つの原子的な操作として、データベース側で非常に効率的に実行できる点です。アプリケーション側で「SELECTしてみて、存在しなければINSERT、存在すればUPDATE」というロジックを記述し、個別にSQLを実行するよりも、ネットワークラウンドトリップやトランザクションオーバーヘッドを大幅に削減できます。

メリット:

挿入と更新を効率的に結合した操作。
バッチ処理でのデータ投入・更新に非常に適している。
ネットワークラウンドトリップとトランザクションオーバーヘッドを最小限に抑えられる。
データベース側で処理されるため高速。

デメリット:

更新対象のテーブルに PRIMARY KEY または UNIQUE KEY が必須。
更新する値は、VALUES 句で指定した挿入データから取得する必要がある。既存の他のカラムの値に基づいた複雑な計算による更新などには不向き。
あくまで「挿入を試みて、重複したら更新」というロジックであり、既存の行を「条件に基づいて」更新することに特化した UPDATE とは用途が異なる（例えば、特定のステータスの行だけを更新するといった細かい制御は難しい）。

この方法は、外部データソースとの同期や、定期的なバッチ処理によるデータ更新において、非常に強力な選択肢となります。

4. 一時テーブルを使った方法

更新したいデータが複雑なクエリ結果であったり、外部ファイルから読み込んだ大量のデータであったり、あるいは既存のテーブルのデータと複雑なロジックで結合・計算する必要がある場合など、前述の CASE や JOIN では対応が難しいシナリオがあります。このような場合、中間データや更新情報を格納するための一時テーブル（TEMPORARY TABLE）を利用する方法が有効です。

この方法は、以下のステップで実行されます。

一時テーブルの作成: 更新に必要な情報（更新対象のキー、更新する値、更新の条件など）を格納するための一時テーブルを作成します。
一時テーブルへのデータ投入: 更新したいデータや計算結果を一時テーブルに投入します。これは INSERT INTO ... SELECT ... や、アプリケーションからの複数行INSERT、LOAD DATA INFILE など様々な方法で実行できます。
一時テーブルとのJOINによるUPDATE: 更新対象のテーブルと作成した一時テーブルをキーで結合し、一時テーブルのデータを使って対象テーブルの行をUPDATEします。
一時テーブルの破棄: 処理が完了したら、一時テーブルを破棄します（セッション終了時に自動的に破棄される場合が多いですが、明示的に DROP TEMPORARY TABLE することも可能です）。

構文（ステップ3のUPDATE部分）:

sql UPDATE table_to_update t JOIN temporary_table tt ON t.key_column = tt.key_column SET t.column1 = tt.value1, t.column2 = tt.value2, ... WHERE -- 必要に応じて一時テーブルや対象テーブルのカラムを使った条件を追加 ...;

これは基本的に「JOINを使った方法」と同じ構文ですが、JOINするテーブルが一時テーブルである点が異なります。

具体的な例:

商品の価格を、特定のサプライヤーからの最新の仕入れ価格に基づいて更新したいとします。仕入れ価格データは日々変動し、CSVファイルで提供されるとします。

一時テーブルの作成: CSVファイルの構造に合わせて一時テーブルを作成します。

sql CREATE TEMPORARY TABLE temp_supplier_prices ( product_id INT PRIMARY KEY, latest_cost DECIMAL(10, 2), markup_percentage DECIMAL(5, 2) );
一時テーブルへのデータ投入: CSVファイルから temp_supplier_prices にデータを投入します。これは LOAD DATA INFILE が最も効率的です。

sql -- 例：CSVファイル 'supplier_prices.csv' からデータをロード LOAD DATA INFILE '/path/to/supplier_prices.csv' INTO TABLE temp_supplier_prices FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 LINES -- ヘッダー行をスキップする場合 (product_id, latest_cost, markup_percentage);

もしデータが別のテーブルの集計結果などであれば、INSERT INTO temp_supplier_prices SELECT ... を使用します。
一時テーブルとのJOINによるUPDATE: products テーブルと temp_supplier_prices を結合し、価格を更新します。ここでは、仕入れ価格にマークアップ率をかけて販売価格を計算するとします。

sql UPDATE products p JOIN temp_supplier_prices tsp ON p.product_id = tsp.product_id SET p.price = tsp.latest_cost * (1 + tsp.markup_percentage / 100), p.last_price_update = NOW() WHERE -- 必要であれば、特定の条件を満たす商品のみを更新 p.status = 'Available';
一時テーブルの破棄:

sql DROP TEMPORARY TABLE temp_supplier_prices;

メリット:

最も柔軟な方法であり、複雑なデータソースや計算に基づいた更新に対応できる。
中間データを一時テーブルに格納することで、複雑なロジックを複数のステップに分けて処理できる。
特に大量のデータを外部から読み込んで更新する場合に効率的（LOAD DATA INFILE と組み合わせられるため）。

デメリット:

一時テーブルの作成、データ投入、UPDATE、破棄と、複数のステップが必要になる。
一時テーブルを作成・使用するためのディスクI/Oやメモリリソースが必要になる。
トランザクション管理がより重要になる（一時テーブルへのデータ投入とUPDATEは同じトランザクション内で実行すべき）。

一時テーブルを使った方法は、更新ロジックやデータソースが複雑な場合に、他の方法では実現困難な処理を可能にします。特に、大量のデータの一括処理において、その柔軟性と効率性が活かされます。

大規模なUPDATEにおける注意点とパフォーマンス最適化

数万行、数十万行、あるいはそれ以上の大量のデータをまとめてUPDATEする場合、単に適切な構文を使うだけでなく、データベースのパフォーマンスと安定性、そしてデータの一貫性を維持するための配慮が不可欠です。不適切な大規模UPDATEは、データベース全体の性能低下、他のトランザクションへの影響（ロック待ち）、レプリケーション遅延、最悪の場合はシステム停止を引き起こす可能性があります。

ここでは、大規模UPDATEを実行する際に考慮すべき主要な注意点とパフォーマンス最適化のテクニックを解説します。

1. トランザクション管理

複数行をまとめてUPDATEする操作は、通常、アトミック（不可分）に行われるべきです。つまり、処理全体が成功するか、あるいは何も変更されずに元に戻るか、のいずれかであるべきです。これを保証するために、トランザクションを使用します。

“`sql
START TRANSACTION;

— ここに大規模UPDATEクエリ（複数でも可）

— 全て成功した場合
COMMIT;

— 途中でエラーが発生した場合や、問題が見つかった場合
— ROLLBACK;
“`

一つの大きなトランザクションで大量のUPDATEを実行することには、データの一貫性を保てるという大きなメリットがありますが、同時にデメリットも伴います。

ロックの長時間保持: トランザクションが完了するまで、更新対象の行（場合によってはテーブル全体やインデックスの一部）にロックが保持されます。これにより、他のトランザクションがそのデータにアクセスしようとした際にロック待ちが発生し、システムの応答性が低下する可能性があります。
undoログの増大: 大量の変更は大量のundoログを生成します。undoログ領域が不足したり、管理オーバーヘッドが増大したりする可能性があります。
リカバリ時間の増加: クラッシュリカバリの際、完了していない長時間のトランザクションをロールバックするのに時間がかかる可能性があります。

これらの問題を軽減するためには、必要に応じて後述する「バッチ処理」を検討します。

2. ロック

InnoDBストレージエンジンを使用している場合、通常は行レベルロックが使用されます。これは、更新対象の特定の行だけをロックするため、他の行へのアクセスは妨げられません。しかし、UPDATEクエリが非常に多くの行を対象とする場合や、適切なインデックスがないためにフルテーブルスキャンが必要になる場合など、行レベルロックだけでは不十分だったり、ロックの管理自体がオーバーヘッドになったりすることがあります。

特に、JOINを使ったUPDATEや複雑なWHERE句では、意図せず広範囲のロックが発生する可能性があります。SHOW ENGINE INNODB STATUS コマンドは、現在のInnoDBの状態、特にロック待ちやデッドロックに関する情報を確認するのに役立ちます。

デッドロックは、2つ以上のトランザクションがお互いが必要とするリソース（ロック）を待機し、処理が進まなくなる状態です。MySQLのInnoDBはデッドロックを自動的に検知し、一方のトランザクションをロールバックしてデッドロックを解消します。しかし、デッドロックが発生しないようにクエリを設計することが重要です。一般的なデッドロック回避策としては、複数のリソース（テーブル、行）にアクセスする場合、常に同じ順序でアクセスするようにアプリケーションやクエリを統一する、トランザクションを可能な限り短く保つ、といった方法があります。

3. インデックス

UPDATE ステートメントのパフォーマンスは、WHERE 句や JOIN 条件で使われるカラムに適切なインデックスが存在するかどうかに大きく依存します。インデックスがない場合、MySQLはテーブル全体をスキャンして更新対象の行を探す必要があり（フルテーブルスキャン）、これは特に大規模なテーブルで非常に非効率的です。

EXPLAIN ステートメントを使って、UPDATEクエリの実行計画を確認し、インデックスが適切に使用されているか、フルテーブルスキャンが発生していないかを確認することが重要です。

sql EXPLAIN UPDATE products SET price = price * 0.9 WHERE category = 'Electronics';

このEXPLAINの出力を見て、type が ALL であったり、rows がテーブルの全行数に近かったりする場合は、WHERE 句に使われているカラム（この例では category）にインデックスがないか、インデックスが効率的に使われていない可能性があります。

ただし、更新対象のカラム自体にインデックスが存在する場合、そのインデックスもUPDATEの度に更新される必要があります。これはUPDATE処理のオーバーヘッドとなる可能性があります。更新されるカラムに不要なインデックスがないか見直すこともパフォーマンス改善につながる場合があります。

4. バッチ処理（チャンク処理）

非常に大量の行（例えば数百万行以上）を一度のSQLステートメントや一つのトランザクションでUPDATEしようとすると、ロック期間が長くなりすぎたり、undoログが巨大になったり、メモリを大量に消費したりする問題が発生しやすくなります。このような場合、更新対象のデータを小さなチャンク（バッチ）に分割して、繰り返しUPDATEを実行する「バッチ処理」あるいは「チャンク処理」が有効です。

バッチ処理の手順例：

更新対象の行を特定するための基準（例: 主キーの範囲、処理フラグなど）を決めます。
小さな塊の行だけを対象とするUPDATEクエリを作成します。これには LIMIT 句や、主キーの範囲を指定する WHERE id BETWEEN X AND Y などが使えます。
各バッチ処理を個別のトランザクションで実行します。
すべてのバッチが完了するまで、ステップ2と3を繰り返します。

例: IDが連番になっているテーブルで、IDを10000行ずつ更新する場合。

“`sql
SET @batch_size = 10000;
SET @last_id = 0;

— 全ての行が処理されるまでループ
— ここはアプリケーションコードやシェルスクリプトでループを組むのが一般的
— MySQLのストアドプロシージャでループを組むことも可能だが、実行時間の問題に注意

— 例: ストアドプロシージャの断片
— SELECT MAX(id) INTO @max_id FROM your_table WHERE your_update_condition;

— WHILE @last_id < @max_id DO
— START TRANSACTION;

UPDATE your_table
SET your_column = your_new_value -- または複雑なCASE/JOIN
WHERE id > @last_id -- 前回のバッチの最後のIDより大きい行を対象
  AND your_update_condition -- 本来の更新条件
ORDER BY id -- ID順に処理することで、次のバッチの開始点を特定しやすくする
LIMIT @batch_size;

— SELECT ROW_COUNT() INTO @rows_updated; — 更新された行数を取得
— IF @rows_updated = 0 THEN
— — 更新対象がなくなったらループを抜ける
— LEAVE;
— END IF;

— — 次のバッチの開始点を決定
— SELECT MAX(id) INTO @last_id FROM your_table WHERE id > @last_id AND your_update_condition LIMIT @batch_size; — 取得した@batch_size行の最大ID

— COMMIT;

— — バッチ間に短い待機時間を設けることで、CPUやIO負荷を軽減し、他の処理への影響を抑えることができる
— SELECT SLEEP(0.1); — 100ミリ秒待機

— END WHILE;
“`

このバッチ処理の利点は以下の通りです。

ロック期間の短縮: 各バッチが独立した短いトランザクションで実行されるため、ロックが保持される時間が短くなります。
リソース消費の抑制: 一度に処理するデータ量が少ないため、メモリ、undoログ、バイナリログの急激な増加を抑えられます。
障害時の影響範囲縮小: 特定のバッチでエラーが発生しても、そのバッチだけをロールバックすればよく、既にコミットされたバッチの変更は保持されます。途中から処理を再開しやすくなります。

デメリットとしては、処理全体の完了までに時間がかかること、バッチ処理のロジックをアプリケーション側またはストアドプロシージャで実装する必要があることが挙げられます。

5. innodb_buffer_pool_size

InnoDBはデータをバッファプールと呼ばれるメモリ領域にキャッシュします。UPDATE操作はデータをディスクから読み込み、変更をメモリ上で行い、最終的にディスクに書き戻す（または非同期に書き出す）プロセスを含みます。innodb_buffer_pool_size が小さいと、更新対象のデータやインデックスがバッファプールに乗り切らず、頻繁にディスクI/Oが発生し、パフォーマンスが低下します。

大規模UPDATEを実行する際は、可能な限り多くのデータがバッファプールに乗るように、innodb_buffer_pool_size を適切に設定しておくことが重要です。ただし、サーバーの総メモリ容量を超えないように注意が必要です。

6. バイナリログ

レプリケーションを使用している場合、大規模UPDATEはバイナリログの生成量に大きな影響を与えます。binlog_format の設定によって挙動が異なります。

STATEMENT: SQLステートメント自体がログに記録されます。大規模UPDATEクエリは1つのステートメントとして記録されるため、ログファイルのサイズは比較的小さく済みます。しかし、非決定的な関数（NOW()、RAND()など）を使用している場合、レプリカスレーブでの実行結果がマスターと異なる可能性があるという問題があります。
ROW: 変更された行のイメージ（更新前後の値）がログに記録されます。大規模UPDATEでは、更新されたすべての行のデータがログに含まれるため、ログファイルが非常に大きくなる可能性があります。これはスレーブでのI/OとSQLスレッドの処理負荷を増大させ、レプリケーション遅延の主要な原因となり得ます。しかし、非決定性の問題はありません。
MIXED: 通常はSTATEMENT形式を使用しますが、非決定的なステートメントや複雑なステートメントの場合に自動的にROW形式に切り替わります。

大規模UPDATEのレプリケーションへの影響を考慮し、binlog_format を適切に設定するか、あるいは一時的にレプリケーションを停止したり、スレーブに遅延を許容したりするなどの対策が必要になる場合があります。

SET sql_log_bin = 0;

このステートメントをUPDATEの前に実行すると、そのセッションのSQLはバイナリログに記録されなくなります。これにより、レプリケーションへの影響を完全に排除できます。しかし、これは非常に危険な操作です。マスターとスレーブのデータに不整合が生じる可能性が極めて高いため、特別な理由がない限り、安易に使用すべきではありません。レプリケーション環境で大規模な一括更新を行う場合は、ROWフォーマットでの実行によるログ増加や遅延を受け入れるか、レプリケーションを一時停止して手動でスレーブを同期するなどの手順を踏むのがより安全です。

7. バックアップ

大規模なデータ変更操作を実行する前には、必ずデータベースのバックアップを取得してください。もしUPDATEが失敗したり、意図しない結果を招いたりした場合でも、バックアップから迅速に元の状態に戻すことができます。これは最も基本的な、そして最も重要な安全策です。

各方法の比較表

ここまで見てきた複数行UPDATEの主な方法について、それぞれの特徴を比較してみましょう。

方法	複雑さ	パフォーマンス (対象件数)	柔軟性 (更新条件/値)	適用ケース	制約
`UPDATE ... WHERE ...`	低	高 (適切インデックス時)	低 (同じ値のみ)	特定条件の全行を同じ値に更新	行ごとに異なる値は設定不可
`UPDATE ... SET CASE ...`	中	中〜高	中 (同一テーブル内)	条件分岐で異なる値を更新 (自テーブルのカラムや固定値に基づく)	別のテーブルのデータに基づく更新は困難
`UPDATE ... JOIN ... SET`	中〜高	中〜高	高	別のテーブルのデータに基づいた更新	JOIN条件や重複行に注意、JOIN効率に依存
`INSERT ... ON DUPLICATE KEY UPDATE (VALUES())`	中	高 (バッチ処理に強い)	中 (挿入データに基づく)	外部データ投入時の挿入 or 更新、バッチでのデータ同期	`PRIMARY KEY` or `UNIQUE KEY` が必須、値はVALUES()から
一時テーブルを使った方法	高	高 (柔軟性が高い)	最高	複雑なデータソース/ロジックでの更新、大規模データの一括処理 (`LOAD DATA INFILE`連携)	複数ステップ必要、一時リソース消費

この表はあくまで一般的な傾向を示しています。実際のパフォーマンスは、テーブルスキーマ、データ量、インデックス、クエリの詳細、サーバー構成など、多くの要因によって変動します。重要なのは、ご自身のシナリオと要件に最も合った方法を選択し、必要に応じて後述のパフォーマンス最適化手法を適用することです。

実例とコードスニペット

これまで解説した方法について、より実践的なシナリオに基づいた具体的なコード例を示します。

シナリオ1: 特定の地域コードを持つ全ユーザーのステータスをアクティブにする

最も基本的な UPDATE ... WHERE ... の例です。

“`sql
— テーブル: users (user_id INT PRIMARY KEY, region_code VARCHAR(10), status VARCHAR(20), …)

— 地域コード ‘JP-TKY’ または ‘JP-OSK’ の全ユーザーのステータスを ‘Active’ に変更
UPDATE users
SET status = ‘Active’,
last_status_change = NOW() — 複数カラムの更新
WHERE region_code IN (‘JP-TKY’, ‘JP-OSK’);

— 更新された行数を確認
SELECT ROW_COUNT();
“`

シナリオ2: セール期間中に特定の商品の価格を割引率に基づいて更新する (CASE)

products テーブルに category と base_price があります。セール期間中は、カテゴリーに応じて異なる割引率を適用して sale_price を設定したいとします。

“`sql
— テーブル: products (product_id INT PRIMARY KEY, name VARCHAR(255), category VARCHAR(50), base_price DECIMAL(10, 2), sale_price DECIMAL(10, 2), …)

UPDATE products
SET
sale_price = CASE category
WHEN ‘Electronics’ THEN base_price * 0.9 — 10% オフ
WHEN ‘Clothing’ THEN base_price * 0.85 — 15% オフ
WHEN ‘Books’ THEN base_price * 0.95 — 5% オフ
ELSE base_price — 上記以外のカテゴリーは割引なし
END,
last_price_update = NOW()
WHERE
— 例: セール対象の商品にフラグが立っている場合
is_on_sale = TRUE;
“`

この例では、WHERE 句でセール対象の商品に絞り込み、その中で CASE 文を使ってカテゴリー別の割引価格を計算しています。

シナリオ3: 最新の売上データに基づいて顧客ランクを更新する (JOIN & 一時テーブルの活用)

customers テーブルに customer_id と customer_rank があり、orders テーブルに order_id, customer_id, order_date, total_amount があります。過去1年間の購入金額合計に基づいて顧客ランクを更新したいとします。JOINを使った方法で、まず過去1年間の購入金額合計を計算するクエリを作成し、それを基にUPDATEします。複雑な計算のため、一時テーブルで中間結果を保持するアプローチも有効です。

JOINを使った方法:

“`sql
— customers テーブル: customer_id (PK), customer_rank VARCHAR(20)
— orders テーブル: order_id (PK), customer_id (FK), order_date DATE, total_amount DECIMAL(10, 2)

— 過去1年間の購入金額合計を計算するサブクエリ
UPDATE customers c
JOIN (
SELECT customer_id, SUM(total_amount) AS total_purchase_last_year
FROM orders
WHERE order_date >= DATE_SUB(CURDATE(), INTERVAL 1 YEAR)
GROUP BY customer_id
) AS recent_purchases ON c.customer_id = recent_purchases.customer_id
SET
c.customer_rank = CASE
WHEN recent_purchases.total_purchase_last_year >= 50000 THEN ‘Platinum’
WHEN recent_purchases.total_purchase_last_year >= 10000 THEN ‘Gold’
ELSE ‘Silver’ — 1年間の購入金額が1万円未満の場合
END
WHERE
— オプション: 最新の購入日から一定期間経過していない顧客のみを対象にするなど
1=1; — 全顧客を対象とする場合は省略または 1=1

— 注意: JOIN結果に含まれない顧客（過去1年間購入がない顧客）は更新されません。
— 全顧客のランクを更新したい場合は、一時テーブルを使うか、LEFT JOINとCOALESCEなどを組み合わせる必要があります。
“`

一時テーブルを使った方法（全顧客を対象とし、購入がない顧客は最低ランクに設定）:

“`sql
— 1. 一時テーブルの作成とデータ投入
CREATE TEMPORARY TABLE temp_customer_purchases (
customer_id INT PRIMARY KEY,
total_purchase_last_year DECIMAL(10, 2)
);

INSERT INTO temp_customer_purchases (customer_id, total_purchase_last_year)
SELECT customer_id, SUM(total_amount)
FROM orders
WHERE order_date >= DATE_SUB(CURDATE(), INTERVAL 1 YEAR)
GROUP BY customer_id;

— 2. 一時テーブルと顧客テーブルをJOINしてUPDATE
UPDATE customers c
LEFT JOIN temp_customer_purchases tcp ON c.customer_id = tcp.customer_id
SET
c.customer_rank = CASE
WHEN tcp.total_purchase_last_year IS NULL THEN ‘Bronze’ — 過去1年間の購入がない顧客
WHEN tcp.total_purchase_last_year >= 50000 THEN ‘Platinum’
WHEN tcp.total_purchase_last_year >= 10000 THEN ‘Gold’
ELSE ‘Silver’
END,
c.last_rank_update = NOW();

— 3. 一時テーブルの破棄
DROP TEMPORARY TABLE temp_customer_purchases;
“`

この一時テーブルの例では、LEFT JOIN を使用することで、過去1年間の購入がない顧客（temp_customer_purchases に対応する行がない顧客、JOIN結果で tcp.total_purchase_last_year が NULL になる行）も含めてUPDATE対象とし、最低ランクを設定しています。より柔軟なロジックに対応できることが分かります。

シナリオ4: 外部システムから取り込んだバッチデータで在庫数と最終更新日時を更新する (INSERT … ON DUPLICATE KEY UPDATE)

products テーブルに product_id (PK), stock_quantity, last_stock_update があります。外部システムから新しい在庫データ（product_id と quantity のリスト）を取得しました。既存商品の在庫は更新し、リストに含まれる新規商品は追加したいです。

“`sql
— 外部から取得したデータ例:
— (101, 55), (105, 5), (201, 120)

INSERT INTO products (product_id, stock_quantity, last_stock_update)
VALUES
(101, 55, NOW()),
(105, 5, NOW()),
(201, 120, NOW()) — product_id 201 は新規
ON DUPLICATE KEY UPDATE
— product_id が重複したら、在庫数と更新日時を新しい値で更新
stock_quantity = VALUES(stock_quantity),
last_stock_update = VALUES(last_stock_update);
“`

この単一のステートメントで、既存商品の更新と新規商品の挿入が同時に、効率的に行われます。

よくある問題とトラブルシューティング

大規模UPDATEや複雑なUPDATEを実行する際には、様々な問題に遭遇する可能性があります。ここでは、よくある問題とその原因、そしてトラブルシューティングのヒントを紹介します。

1. ロック待ち (Lock Waits)

症状: UPDATEクエリがなかなか完了しない、あるいは他のクエリが突然遅くなった。SHOW PROCESSLIST でUPDATEクエリが Waiting for table metadata lock や waiting for handler commit など、ロック関連のステータスで止まっている。
原因: 他のトランザクションがUPDATE対象の行やテーブルにロックをかけている。または、大規模なUPDATEが長時間にわたってロックを保持している。
対策:
- SHOW ENGINE INNODB STATUS を実行し、トランザクション、ロック、待機中のロックリクエストに関する詳細情報を確認する。どのトランザクションがどのロックを保持し、どのトランザクションがそれを待っているかが分かります。
- ロックを保持している長時間実行中のクエリやアイドル状態のトランザクションを特定し、必要であれば KILL コマンドで終了させる（ただし、予期しないデータ状態になるリスクがあるため慎重に）。
- UPDATEクエリのトランザクションを可能な限り短く保つ。
- 前述のバッチ処理を検討し、ロック期間を短縮する。
- WHERE 句や JOIN 条件に適切なインデックスが存在することを確認する。
- アプリケーション側で、データベースアクセス時にロック競合を最小限にするような設計を考慮する。

2. デッドロック (Deadlocks)

症状: UPDATEクエリがエラーコード 1213 (Deadlock found when trying to get lock; try restarting transaction) で失敗する。
原因: 複数のトランザクションが、お互いが必要とするロックを待機し、処理が進まなくなる状態。
対策:
- SHOW ENGINE INNODB STATUS の LATEST DETECTED DEADLOCK セクションを確認し、デッドロックに関与したトランザクション、保持していたロック、要求していたロックの詳細を把握する。
- アプリケーションやストアドプロシージャで、複数のテーブルや行を操作する際に、常に同じ順序でロックを取得するようにコーディング規約を定める。
- トランザクションを短く保つ。
- 必要であれば、デッドロックが発生した場合にトランザクションをリトライするロジックをアプリケーションに実装する。

3. パフォーマンスの急激な低下

症状: 特定のUPDATEクエリを実行すると、CPU使用率が急上昇したり、ディスクI/Oが跳ね上がったり、他のクエリも全体的に遅くなったりする。
原因:
- WHERE 句や JOIN 条件に適切なインデックスがない（フルテーブルスキャン）。
- 更新対象の行数が非常に多い。
- 更新対象のカラムに多数のインデックスがあり、インデックス更新のオーバーヘッドが大きい。
- innodb_buffer_pool_size が小さすぎる。
- バイナリログ（特にROW形式）の書き込みがボトルネックになっている。
- 統計情報が古く、オプティマイザが非効率な実行計画を選択している。
対策:
- EXPLAIN で実行計画を確認し、インデックスの使用状況、JOINタイプ、スキャン行数などをチェックする。必要であればインデックスを追加・修正する。
- バッチ処理を導入して、一度に処理するデータ量を減らす。
- 不要なインデックスを削除する。
- innodb_buffer_pool_size や innodb_log_file_size などのInnoDB関連パラメータを見直す。
- ANALYZE TABLE コマンドでテーブルの統計情報を最新の状態に更新する。
- ディスクI/Oのボトルネックであれば、より高速なストレージ（SSDなど）への移行を検討する。

4. `Rows matched` と `Changed` の違い

UPDATE ステートメントの実行結果には、Rows matched: N Changed: M Warnings: W のように表示されます。

Rows matched: WHERE 句の条件に一致した行の数。これらの行がUPDATEの対象として特定されました。
Changed: Rows matched の行のうち、実際に何らかのカラムの値が更新された行の数。例えば、SET col = value WHERE col = value のように、既存の値と同じ値に更新しようとした場合、Rows matched は条件に一致した行数になりますが、実際には値が変わらないため Changed は0になります。

大規模UPDATEで Changed の数が期待と著しく異なる場合は、更新条件や SET 句の値が意図通りになっていない可能性があります。

5. エラーメッセージ

構文エラー (Error 1064): SQL構文が間違っています。スペルミス、予約語の使用、句読点の誤りなどを確認します。
カラム/テーブル不明 (Error 1054, 1146): 指定したカラムやテーブルが存在しません。テーブル名、カラム名、エイリアスの指定が正しいか確認します。JOINを使ったUPDATEでエイリアスを付けている場合、SET 句のカラム名に正しいエイリアスをプレフィックスとして付けているか確認します。
重複キー違反 (Error 1062): INSERT ... ON DUPLICATE KEY UPDATE 以外で、またはその中でも意図せず、主キーやユニークキー制約に違反するような値を挿入・更新しようとしています。データの重複がないか、キー制約を満たすような値になっているか確認します。INSERT ... ON DUPLICATE KEY UPDATE を使用している場合は、重複が期待される挙動であり、エラーではなく更新として処理されるはずです。

エラーメッセージを注意深く読み、原因を特定することがトラブルシューティングの第一歩です。MySQLのエラーコードとメッセージは公式ドキュメントで確認できます。

まとめ

MySQLで複数行をまとめてUPDATEする方法は、単に「複数行を更新する」という表面的な目的だけでなく、データベース操作の効率性、パフォーマンス、そしてデータの一貫性を確保するための重要なテクニックです。1行ずつUPDATEする方法と比較して、まとめてUPDATEする方法はネットワークラウンドトリップ、SQL解析、トランザクションオーバーヘッド、ロック管理などのコストを大幅に削減し、特に大規模なデータセットに対する処理においてその差は顕著になります。

本記事では、複数行UPDATEの様々なアプローチを詳細に解説しました。

最もシンプルで一般的なのは UPDATE ... WHERE ... ですが、これは全ての対象行を同じ値に更新する場合に限られます。
行ごとに異なる値を更新したい場合は、CASE 文を使う方法、別のテーブルのデータに基づいて更新する JOIN を使う方法があります。
バッチでデータを投入しつつ、既存の行は更新したい場合は INSERT ... ON DUPLICATE KEY UPDATE 構文と VALUES() 関数が非常に強力です。
複雑な更新ロジックや外部データとの連携には、一時テーブルを使った方法が最も柔軟に対応できます。

どの方法を選択すべきかは、更新要件、更新対象のデータ量、更新する値の決定方法（固定値、自テーブル内の別カラム、他テーブルのデータ、計算結果など）によって異なります。それぞれの方法のメリット・デメリットを理解し、シナリオに応じて最適なものを選択することが重要です。

さらに、特に大規模なUPDATEを実行する際には、パフォーマンスと安全性への徹底的な配慮が不可欠です。トランザクションによるアトミック性の保証、ロックの挙動理解とデッドロック対策、適切なインデックスの使用、そして何よりも大量データを扱う際のバッチ処理（チャンク処理）の導入は、安定したシステム運用には欠かせないテクニックです。また、大規模な変更を伴う操作の前には、必ずデータベースのバックアップを取得する習慣をつけましょう。

この記事が、MySQLで複数行を効率的かつ安全にUPDATEするための実践的な知識となり、あなたのデータベース運用やアプリケーション開発に役立つことを願っています。データベースはシステムの心臓部であり、その効率的な操作はアプリケーション全体の性能に直結します。今回学んだ様々な方法と注意点を活用し、より堅牢で高性能なシステムを構築・運用してください。

注釈: 本記事は、MySQL 8.0 を想定して記述しています。一部の機能や挙動は、バージョンによって異なる場合があります。特に、ストレージエンジンがMyISAMの場合はテーブルロックが基本となるため、パフォーマンスやロックの挙動が大きく異なります。