あなたのシナリオでは、分離レベルをスナップショットに明示的に設定することをお勧めします。これにより、ロックを防ぐことで読み取りが書き込み (挿入と更新) の邪魔になるのを防ぐことができますが、それらの読み取りは依然として「良い」読み取りになります (つまり、ダーティ データではありません - NOLOCK とは異なります)
通常、クエリでロックの問題がある場合、適用されるロックを手動で制御します。例えばページ/テーブル レベルのロックを回避するために行レベルのロックを使用して更新を行い、読み取りを readpast に設定します (いくつかのシナリオでは、一部のデータが失われる可能性があることを受け入れます)。>
EDIT-- すべてのコメントを回答にまとめる
最適化プロセスの一環として、SQL Server は、変更されていないことがわかっているページでコミットされた読み取りを取得することを回避し、より弱いロック戦略に自動的にフォールバックします。あなたの場合、SQL Server はシリアル化可能な読み取りから反復可能な読み取りにドロップします。
Q:分離レベルの削除に関する有益な情報をありがとうございます。 SELECT に明示的なトランザクションを使用していないことを考えると、最初に Serializable IsolationLevel を使用する理由を考えられますか?暗黙のトランザクションは ReadCommitted を使用すると理解していましたか?
A:デフォルトでは、SQL Server は Read Commmited がデフォルトの分離レベルである場合に使用しますが、クエリでロック戦略を追加で指定しない場合は、基本的に SQL Server に対して「最善だと思うことを行いますが、私の好みです」と言っているのと同じです。コミットされた読み取りです」。 SQL Server は自由に選択できるため、クエリを最適化するために選択します。 (SQL サーバーの最適化アルゴリズムは非常に複雑で、私自身も完全には理解していません)。トランザクション内で明示的に実行しなくても、SQL Server が使用する分離レベルには影響しません。
Q:最後に、クエリを最適化するために SQL Server が分離レベル (およびおそらく必要なロックの数) を増やすことは合理的だと思いますか?最後に使用された分離レベルを継承した場合、プールされた接続の再利用がこれに影響するかどうかも疑問に思っていますか?
A:SQL サーバーは、「ロック エスカレーション」と呼ばれるプロセスの一部としてこれを行います。 http://support.microsoft.com/kb/323630 から 、私は引用します。通常、SQL Server の既定の動作では、ロックのエスカレーションが発生するのは、パフォーマンスが向上するポイント、または過剰なシステム ロック メモリをより適切なレベルに減らす必要がある場合のみです。ただし、一部のアプリケーションまたはクエリの設計では、望ましくないときにロックのエスカレーションがトリガーされ、エスカレートされたテーブル ロックが他のユーザーをブロックする可能性があります。
ロックのエスカレーションは、クエリを実行する分離レベルを変更することとまったく同じではありませんが、SQL Server がデフォルトの分離レベルで許可されている以上のロックを取得するとは予想していなかったので、これには驚きました。