在我们的应用程序登录过程中，运行了几个查询，所有查询都验证了登录。在评估它们时，我注意到其中一个查询是在没有NOLOCK提示的情况下运行的。
似乎没有任何特别危险的脏读，因为数据几乎不会改变。
通过一次又一次尝试失败登录的人尝试DOS类型攻击来考虑它我建议缺少NOLOCK会降低我们失败的门槛。
我认为这是一次极不可能的DOS攻击（我认为Web服务器会先行）但是添加NOLOCK应该会让它变得不可能。
那么，我是过分还是微不足道？
答案 0 :(得分：3)
对您的服务器进行DoS尝试时，您是否担心NOLOCK是最不担心的。
我不会出汗。
正如你所说，如果数据很少改变，那么拥有NOLOCK可能不会受到伤害。
答案 1 :(得分：2)
是的，你过分琐事。
如果您受到DOS攻击，那么SQL授权调用上的NOLOCK是您最不担心的。实施一些DOS检测，故障跟踪+油门，甚至一些不会影响用户但会减慢攻击的计划暂停......
答案 2 :(得分：0)
这也是一种非常罕见的情况，但仍然是：目前有人停用了用户以防止他们登录，NOLOCK允许他们进入。可能是一个需要立即锁定的流氓用户/黑客/员工？ / p>
你必须关注这个特殊情况才能放弃NOLOCK的性能优势。
答案 3 :(得分：0)
如果您经常在更广泛的交易中频繁调用该查询，NOLOCK可能会提高您的性能。
考虑脏读的性质 - 可能发生的时间窗口是否真的至关重要？例如您在授权角色中添加或删除某人的位置。
在添加方案中，脏读将在该尝试失败。 （访问被拒绝）
在删除方案中，脏读将对该尝试起作用。 （准入访问）
如果数据通过手动操作改变，例如人际互动 - 他们的“延迟”余量通常比数据库高得多/不确定！
答案 4 :(得分：0)
通过查看权限，您可以更好地保护您的桌面。像这样的表不应该允许任何直接访问，所有访问都应该来自存储过程以及在它们上设置的权限。