UPDATE 文は、LindormTable 内のデータを更新します。このトピックでは、UPDATE の構文と注意事項について説明します。
適用対象のエンジンおよびバージョン
UPDATE文は LindormTable のみに適用されます。UPDATE文は LindormTable 2.3.2 以降でサポートされています。現在のバージョンの確認またはアップグレード方法については、「LindormTable バージョンガイド」および「マイナーバージョンの更新」をご参照ください。
構文
update_statement ::= UPDATE [hint_clause] table_identifier
SET column_identifier = value (',' column_identifier = value ) *
WHERE where_clause
where_clause ::= relation ( AND|OR relation )*
relation ::= column_name operator term
| '(' column_name ( ',' column_name )* ')' operator tuple_literal
operator ::= '=' | '<' | '>' | '<=' | '>=' | '!=' | IN | IS NOT? NULL | LIKE制限事項
プライマリキーを更新することはできません。プライマリキーは行の一意な識別子です。プライマリキーを更新することは、新しい行を挿入することと同等です。新しい行を挿入するには、
UPSERT文を使用してください。複数行に対する原子性は保証されません。一括更新中にエラーが発生した場合、一部の行のみが正常に更新され、他の行は失敗することがあります。エラーが発生しない場合は、すべての行が正常に更新されます。たとえば、
UPDATE sensor SET c1 = 2, c2=4,c4 =6 WHERE p1 = 1;のような範囲更新が該当します。べき等性は保証されません。
UPDATE文はべき等性を保証しません。累積などの操作において、エラーが発生するとUPDATEが再試行され、結果が不正確になる可能性があります。べき等性を持つ SQL:
UPDATE sensor SET c1 = 2 WHERE p1 = 1;。この文は、初期適用後も複数回実行しても結果が変化しません。べき等性を持たない SQL:
UPDATE sensor SET c1 = c1 + 1 WHERE p1 = 1;。この文を再試行すると、値が複数回インクリメントされるため、結果が不正確になります。
行をまたいだトランザクションはサポートされていません。1 つの
UPDATEコマンドで複数行を更新する際にエラーが発生すると、一部の行のみが正常に更新され、他の行は失敗することがあります。説明式を使用して非プライマリキーのフィールドを更新する場合、単一行のみを更新でき、かつすべてのプライマリキーを指定する必要があります。これにより、更新対象の行を迅速に特定できます。例については、「列値の増分」をご参照ください。
c1 =1のようなスカラー更新が部分的に失敗した場合は、更新操作をリトライしてください。
使用例
以下のテーブルスキーマおよびデータがあると仮定します。
-- sensor という名前のテーブルを作成します。
CREATE TABLE sensor (
p1 INTEGER NOT NULL,
c1 INTEGER,
c2 VARCHAR,
c3 VARCHAR,
PRIMARY KEY(p1)
);
-- データを 1 行挿入します。
UPSERT INTO sensor(p1, c1, c2, c3) VALUES(1,1,'a','a');テーブル内のデータは次のとおりです。
+----+----+----+----+
| p1 | c1 | c2 | c3 |
+----+----+----+----+
| 1 | 1 | a | a |
+----+----+----+----+プライマリキーに基づくデータ更新
UPDATE sensor SET c2='b' WHERE p1=1;結果の確認
SELECT * FROM sensor; 文を実行して、データが更新されたことを確認します。期待される結果は次のとおりです。
+----+----+----+----+
| p1 | c1 | c2 | c3 |
+----+----+----+----+
| 1 | 1 | b | a |
+----+----+----+----+非プライマリキーに基づくデータ更新
LindormTable のバージョンは 2.8.2.29 以降である必要があります。現在のバージョンの確認およびコンソールでのマイナーバージョンの 2.8.2.29 以降へのアップグレード方法については、「現在のバージョンの確認」および「マイナーバージョンのアップグレード」をご参照ください。
この機能はパブリックプレビュー段階です。ご利用になるには、Lindorm テクニカルサポートまでご連絡ください。DingTalk ID は s0s3eg3 です。
UPDATE sensor SET c3='b' WHERE c1=1;結果の確認
SELECT * FROM sensor; 文を実行して、データが更新されたことを確認します。期待される結果は次のとおりです。
+----+----+----+----+
| p1 | c1 | c2 | c3 |
+----+----+----+----+
| 1 | 1 | b | b |
+----+----+----+----+列値の増分
LindormTable のバージョンは 2.7.6 以降である必要があります。現在のバージョンの確認およびコンソールでのマイナーバージョンの 2.7.6 以降への更新方法については、「現在のバージョン」および「マイナーバージョンの更新」をご参照ください。
この機能はパブリックプレビュー段階です。ご利用になるには、Lindorm テクニカルサポートまでご連絡ください。DingTalk ID は s0s3eg3 です。
UPDATE sensor SET c1 = c1 + 1 WHERE p1 = 1;結果の確認
SELECT * FROM sensor; 文を実行して、データが更新されたことを確認します。期待される結果は次のとおりです。
+------+------+------+------+
| p1 | c1 | c2 | c3 |
+------+------+------+------+
| 1 | 2 | b | b |
+------+------+------+------+よくある質問
Q1:データ更新が完了した後、影響を受けた行数(AFFECTED ROWS)が期待と異なるのはなぜですか?
A1:検索インデックステーブルとプライマリテーブルのデータは強整合性ではなく、データ同期に遅延が発生する可能性があります。プライマリテーブルに検索インデックスを作成しており、更新条件がインデックスキー列にヒットする場合、データ同期の遅延により更新が失敗することがあります(つまり、
AFFECTED ROWS:が期待と異なります)。すべてのデータ同期が完了するまで待機した後、再度更新操作を実行してください。検索インデックスの同期遅延に関する詳細については、「よくある質問」をご参照ください。Q2:一括更新中にタイムアウトエラーが発生するのはなぜですか?
A2:1 回の操作で 10,000 行を超える更新を行わないでください。大規模な一括更新を行う場合は、UPDATE 文に _l_operation_timeout_ HINT パラメーターを追加してタイムアウト期間を延長してください。例:
UPDATE /*+ _l_operation_timeout_(30000) */ table1 SET a=1 WHERE b=2;。_l_operation_timeout_ パラメーターの詳細については、「hintOption パラメーターの説明」をご参照ください。HINT を追加してもタイムアウトエラーが解消しない場合は、Lindorm コンピュートエンジンを使用して一括更新を実行することを検討してください。