SELECT…FOR UPDATEを使用する場合

背後のユースケースを理解するのを手伝ってくださいSELECT ... FOR UPDATE。

質問1：次のSELECT ... FOR UPDATE使用例は良い例ですか？

与えられた：

• 部屋[id]
• タグ[ID、名前]
• room_tags [room_id、tag_id]
  • room_idとtag_idは外部キーです

アプリケーションは、すべての部屋とそのタグをリストする必要がありますが、タグのない部屋と削除された部屋を区別する必要があります。SELECT ... FOR UPDATEを使用しない場合、次のことが起こります。

• 最初は：
  • 部屋には [id = 1]
  • タグに含まれる [id = 1, name = 'cats']
  • room_tagsには [room_id = 1, tag_id = 1]
• スレッド1： SELECT id FROM rooms;
  • returns [id = 1]
• スレッド2： DELETE FROM room_tags WHERE room_id = 1;
• スレッド2： DELETE FROM rooms WHERE id = 1;
• スレッド2：[トランザクションをコミットします]
• スレッド1： SELECT tags.name FROM room_tags, tags WHERE room_tags.tag_id = 1 AND tags.id = room_tags.tag_id;
  • 空のリストを返します

スレッド1は、部屋1にはタグがないと考えますが、実際には部屋は削除されています。この問題を解決するには、スレッド1をSELECT id FROM rooms FOR UPDATEにする必要があります。これにより、roomsスレッド1が完了するまでスレッド2が削除されなくなります。あれは正しいですか？

質問2：場合は1が使用するSERIALIZABLEトランザクション分離が対READ_COMMITTEDとSELECT ... FOR UPDATE？

回答は移植可能であることが期待されます（データベース固有ではありません）。それが不可能な場合は、その理由を説明してください。

部屋とタグの間の一貫性を実現し、削除された部屋が戻されないことを保証する唯一のポータブルな方法は、でそれらをロックすることSELECT FOR UPDATEです。

ただし、一部のシステムでは、ロックは並行性制御の副作用であり、FOR UPDATE明示的に指定しなくても同じ結果が得られます。

この問題を解決するには、スレッド1をSELECT id FROM rooms FOR UPDATEにする必要があります。これにより、roomsスレッド1が完了するまでスレッド2が削除されなくなります。あれは正しいですか？

これは、データベースシステムが使用している同時実行制御によって異なります。

• MyISAMin MySQL（および他のいくつかの古いシステム）は、クエリの実行中はテーブル全体をロックします。

• ではSQL Server、SELECTクエリは調査したレコード/ページ/テーブルに共有ロックを設定し、DMLクエリは更新ロックを設定します（後で排他ロックに昇格または共有ロックに降格されます）。排他ロックは共有ロックと互換性がないため、SELECTまたはDELETEクエリは、別のセッションがコミットするまでロックされます。

• 使用のデータベースではMVCC（のようなOracle、PostgreSQL、MySQLとInnoDB）、DMLクエリは、（1または別の方法で）レコードのコピーを作成し、一般読者は作家やその逆をふさがないようにしてください。これらのデータベースの場合、SELECT FOR UPDATEは便利です。同じように、別のセッションがコミットするまでSELECT、いずれかまたはDELETEクエリをロックSQL Serverします。

とき1を使うべきREPEATABLE_READ対トランザクション分離をREAD_COMMITTED持ちますかSELECT ... FOR UPDATE？

一般に、REPEATABLE READ幻の行（変更されるのではなく、別のトランザクションで表示または非表示になった行）を禁止しません。

• ではOracle以前のPostgreSQLバージョンでは、REPEATABLE READ実際の同義語ですSERIALIZABLE。基本的に、これはトランザクションが開始した後に加えられた変更をトランザクションが認識しないことを意味します。したがって、この設定では、最後のThread 1クエリは部屋が削除されていないかのように部屋を返します（希望どおりである場合とそうでない場合があります）。削除された部屋を表示したくない場合は、行をロックする必要がありますSELECT FOR UPDATE

• ではInnoDB、REPEATABLE READとSERIALIZABLEは異なりSERIALIZABLEます。モードのリーダーは、評価するレコードに次のキーのロックを設定しDML、それらの同時実行を効果的に防止します。したがってSELECT FOR UPDATE、シリアライズ可能モードでの必要はありませんが、REPEATABLE READまたはで必要READ COMMITEDです。

分離モードの標準では、クエリに特定の癖が見られないことが規定されていますが、その方法は定義されていないことに注意してください（ロックの有無、MVCCまたはその他の方法で）。

「必要ない」と言ったときは、「SELECT FOR UPDATE特定のデータベースエンジンの実装による副作用のために」本当に追加する必要がありました。

短い答え：

Q1：はい。

Q2：どちらを使用してもかまいません。

長い答え：

A select ... for updateは（それが意味するように）特定の行を選択しますが、現在のトランザクションによってすでに更新されているかのように（またはIDの更新が実行されたかのように）それらをロックします。これにより、別のトランザクションがこれらの行を変更することなく、現在のトランザクションで再度更新してコミットすることができます。

別の見方をすると、次の2つのステートメントがアトミックに実行されているかのようです。

select * from my_table where my_condition;

update my_table set my_column = my_column where my_condition;

の影響を受ける行my_conditionがロックされているため、他のトランザクションが行を変更することはできません。したがって、トランザクション分離レベルでは、ここでは違いはありません。

トランザクション分離レベルはロックとは独立していることにも注意してください。別の分離レベルを設定しても、トランザクションによってロックされている別のトランザクションの行をロックして更新することはできません。

トランザクション分離レベルが保証するのは（異なるレベルで）、トランザクションの進行中のデータの一貫性です。