アプリケーションへのログインの過程で、ログインを検証するためにいくつかのクエリが実行されました。それらを評価すると、クエリの 1 つが NOLOCK ヒントなしで実行されることに気付きました。
データはほとんど変更されないため、ダーティ リードの危険性は特にないようです。
ログインの失敗を何度も試みた誰かによる DOS タイプの攻撃の試みから考えてみると、NOLOCK の欠如が失敗のしきい値を下げることを示唆しています。
これが DOS 攻撃の結果である可能性は非常に低いと思います (Web サーバーが最初に実行されると思います) が、NOLOCK を追加すると、可能性が低いから不可能になるはずです。
それで、私は過度または些細なことですか？
NOLOCK があるかどうかは、サーバーに対する DoS 攻撃の際の心配事ではありません。
私はそれを汗をかきません。
あなたが言うように、データがめったに変更されない場合は、そこに NOLOCK があってもおそらく害はありません。
はい、あなたは過度に平凡です。
DOS 攻撃にさらされている場合、SQL 承認呼び出しでの NOLOCK は心配する必要がありません。いくつかの DOS 検出、障害追跡 + スロットル、さらにはユーザーに影響を及ぼさない計画的な一時停止を実装しますが、攻撃を遅くします...
You would protect your table far better by looking at the permissions to it. A table like this should not allow any direct access, all access should be from stored procs and the permissions set on them instead.
また、非常にまれなケースですが、それでも、誰かがユーザーを非アクティブ化してログインできないようにした瞬間に、NOLOCK がそのユーザーを許可します。すぐにロックアウトする必要がある悪意のあるユーザー/ハッカー/従業員である可能性はありますか?
NOLOCK のパフォーマンス上の利点を放棄するには、この特定のシナリオについて考慮する必要があります。
NOLOCK は、特に広範なトランザクションでそのクエリを頻繁に呼び出す場合、パフォーマンスを向上させる可能性があります。
ダーティ リードの性質を考慮してください。ダーティ リードが発生する時間枠は本当に重要でしょうか? たとえば、承認された役割から誰かを追加または削除する場合。
追加のシナリオでは、ダーティ リードはその試行で失敗します。（アクセスが拒否されました）
削除のシナリオでは、ダーティ リードがその試行で機能します。(アクセス許可)
人間の操作などの手動操作によってデータが変更された場合、「レイテンシ」のマージンは通常、データベースよりもはるかに高く/不確定です!