開発者がクエリで WITH(nolock) を使用しているのを見たことがありますが、デメリットはありますか? また、クエリのデフォルトの実行モードは何ですか? 私のデータベースにはインデックスがありません。
データベースの select ステートメントのパフォーマンスを向上させる他の方法はありますか?
5782 次
3 に答える
2
これについては、ネット上に数多くの記事があります。主なリスクは、NOLOCKコミットされていないデータをテーブルから読み取ることができることです (ダーティ リード)。たとえば、http://msdn.microsoft.com/en-us/library/aa259216 (v=sql.80).aspxまたはhttp://www.techrepublic.com/article/using-nolock-and-を参照してください。 readpast-table-hints-in-sql-server/6185492
于 2011-03-21T10:21:59.803 に答える
2
nolock に関する一般的な誤解は、実行中にデータベースにロックを設定しないというものです。技術的には、スキーマ安定性 (sch-s) ロックを発行するため、ロックの「いいえ」の部分はクエリのデータ側に関連しています。
ほとんどの場合、これは開発者による時期尚早の最適化です。これにより、クエリが高速になると聞いているからです。
ダーティ リードを受け入れる (そして、同じ行を 2 回読み取る可能性がある) 証拠と妥当性を備えていない限り、使用しないでください。それが必要であること。
于 2011-03-21T10:25:42.837 に答える
0
NOLOCK頻繁に使用されるテーブルから古いデータを読み取る場合に非常に役立ちます。次の例を考えてみましょう。
非アクティブなプロジェクトのデータにアクセスするためのストアド プロシージャがあります。このストアド プロシージャが、古いデータの読み取り中に頻繁に使用される Projects テーブルをロックすることは望ましくありません。
NOLOCKまた、次のような場合のように、ダーティ リードが問題にならず、データが頻繁に変更されない場合にも役立ちます。
国、通貨などのリストをデータベースから読み取り、フォームに表示します。ここでは、データは変更されず、ダーティ リードはほとんど発生しないため、大きな問題にはなりません。
ただし、SQL Server 2005 以降では、行のバージョン管理のため、NOLOCK の利点はほとんどありません。
于 2017-11-24T03:14:37.433 に答える