SQL Server テーブルに対して update ステートメントを実行する必要があります。このテーブルは、同時に別のプロセスによって使用されています。デッドロックが発生することがあるため、これらのデッドロックを回避または最小限に抑えるために、どの分離レベルをお勧めしますか?
4 に答える
READ UNCOMMITTED
ただし、これにより、トランザクションがコミットされる前にプロセスがデータを読み取ることができます。これは、ダーティ リードと呼ばれます。参考文献
行のバージョン管理を有効にすることをお勧めします。更新により行の新しいバージョンが作成され、他の選択ステートメントは、このバージョンがコミットされるまで古いバージョンを使用します。これを行うには、READ_COMMITTED_SNAPSHOT モードをオンにします。ここに詳細があります。行のバージョンの維持に伴うオーバーヘッドがありますが、UPDATE/SELECT のデッドロックは解消されます。
ここで READ UNCOMMITTED を使用するという提案は問題ありませんが、そもそもなぜデッドロックが発生するのかという問題を実際に回避しています。ダーティ リードを気にしないのであれば問題ありませんが、分離の利点 (一貫性など) が必要な場合は、アプリケーションで適切なロック戦略を考え出すことをお勧めします。
私はそれについてあなたに答えを持っていません - 私はそれについて自分でいくつかの戦略を練っています. 議論については、この質問のコメントを参照してください。
カーソルまたはループを使用して、バッチ内の少数の行を更新します。これにより、SQLServerがテーブルロックにエスカレートするのを回避できます。
スナップショット分離を検討してください。このレベルの分離を使用することは、一貫性と速度の間の適切な妥協点です。これを言うと炎上するかもしれませんが、この分離レベルではデッドロックに遭遇するのははるかに難しいと思います。
デッドロック状態を回避するためにこれが正しいことであるかどうかは、まったく別の問題です。