SQL Server-NOLOCK接続とREADONLY接続
SQL Server 2008以降では、接続がREADONLYとして構成されている場合でも、SELECTステートメントの各テーブルで（NOLOCK）を使用する必要がありますか？
ロックは主に、ACIDに準拠したデータの書き込みと読み取り、書き込みと取得を支援するために使用されます。したがって、「読み取り専用」クエリは、ロックの複数のレイヤーを持つことができます。デフォルトでは、MS SQL Serverは悲観的ロックを使用しますが、Oracleは楽観的ロックを使用します。つまり、SQL Serverでは、デフォルトで読み取りは常に書き込みをブロックし、その逆も同様です。 Oracleのデフォルトの分離レベルでは、読み取りは書き込みをブロックしません。したがって、分離レベルに精通していない場合、およびダーティリードに問題がない場合は、技術的に可能です。ただし、そうする必要はありません。
いくつかの問題について読んでください NoLockと代替案に直面します。
コピーペースト：
NOLOCKエフェクト
あなたが心配する必要がある影響は何ですか？そうですね、Andrew Kellyのような他の人がこれについて前に説明しました。PaulWhiteはかなり深く掘り下げています。これらの検索結果は非常にわかりやすく、Kendra Littleはそれについてのビデオさえ持っています…しかしとにかく指摘します。
「ダーティーリード」–これはほとんどの人が知っているものです。コミットされていないデータを読み取ることができ、読み取った後しばらくしてロールバックされる可能性があります。つまり、技術的に存在することのないデータを読み取ったことになります。
行の欠落–割り当てスキャンの動作方法により、他のトランザクションは、まだ読んでいないデータをチェーン内のすでに読んだ前の場所に移動するか、スキャンの後ろに新しいページを追加する可能性があります。まったく見えない。
行を2回読み取る–同様に、既に読み取ったデータをチェーン内の後の場所に移動できます。つまり、2回読み取ることになります。
同じ行の複数のバージョンを読み取る– READ UNCOMMITTEDを使用すると、存在しなかったバージョンの行を取得できます。たとえば、同時ユーザーによって変更された一部の列は表示されますが、それらの変更がすべての列に反映されているわけではありません。これは単一の列内でも発生する可能性があります（Paul Whiteのすばらしい例を参照）。
インデックスの破損–確かにINSERT/UPDATE/DELETEステートメントでNOLOCKを使用していませんが、使用している場合は、SQL Server 2014でもこの構文が廃止され、破損を引き起こす可能性があることに注意してくださいRTM –詳細については、このヒントを参照してください更新しようとしているビューのヒントも確認する必要があることに注意してください。
読み取りエラー–読み取り中に基になるデータが移動または削除される可能性があるため。
ここのほとんどの人は、WITH (NOLOCK)を使用する場合でも、慎重に使用する必要があると言っています。
WITH (NOLOCK)がREADONLYモードのデータベースで目的を果たすかどうかを尋ねていると仮定します。 WITH (NOLOCK)は、クエリ中にテーブルの排他ロックを無視するために最もよく使用されます。更新、挿入、または削除ができない場合、READONLYデータベースに排他ロックをかけないでください（一部のSELECTクエリが明示的にそうしない限り）。したがって、実際には、READONLYデータベースに対するクエリでWITH (NOLOCK)を使用しても、有益なメリットはありません。