[解決済み] NOLOCK (Sql Server hint)はバッドプラクティスか？

質問

私は、以下のようなウェブサイトやアプリケーションを作る仕事をしています。 ではなく 例えば、銀行のソフトウェア、宇宙飛行、集中治療モニタリング・アプリケーションなどです。このアイデアは分かりますよね。

さて、このような大きな免責事項がありますが、いくつかの Sql ステートメントで NOLOCK ヒントを使用することは悪いことなのでしょうか。数年前、仲間の Sql 管理者によって、もし私が "ダーティ リード" に満足しているならば NOLOCK を使用すべきであり、各リードがテーブル/行/何かをロックしないので私のシステムからもう少し多くのパフォーマンスを得ることができると提案されました。

また、デッドロックが発生している場合、これは素晴らしい解決策であると言われました。そのため、私は数年間その考えに従っていましたが、ある Sql の第一人者がランダムなコードで私を助け、私の SQL コードにあるすべての NOLOCKS に気づきました。私は丁重に叱られ、彼はそれを説明しようとしたのですが（なぜそれが良いことではないのか）、私はちょっと分からなくなってしまったのです。彼の説明の本質は、「より深刻な問題に対する応急処置だ・・・特にデッドロックを起こしている場合は。そのため、問題の根本を解決してください』ということです。

私は最近、この件についていくつかググってみたところ、次のようなものに出会いました。 この記事 .

そこで、sql dbの達人である先生方にご教示いただけないでしょうか。

どのように解決するのでしょうか？

NOLOCK ヒントで、トランザクションの分離レベルが SELECT ステートメントのトランザクション分離レベルは READ UNCOMMITTED . これは、クエリがダーティで一貫性のないデータを見る可能性があることを意味します。

これはルールとして適用するのは良いアイデアではありません。このダーティリードの動作がミッションクリティカルなWebベースのアプリケーションにとって問題ないとしても、NOLOCKスキャンは、ロック保護の欠如の結果、データ移動によりクエリーを終了させる601エラーを引き起こす可能性があります。

以下を読むことをお勧めします。 スナップショット分離が役立つ場合と害になる場合 - MSDN では、ほとんどの状況で SNAPSHOT ではなく READ COMMITTED SNAPSHOT を使用することを推奨しています。