sql-server - 在这种情况下 READ UNCOMMITTED/NOLOCK 安全吗？

Question

我知道快照隔离可以解决这个问题，但我想知道 NOLOCK 在这种特定情况下是否安全，这样我就可以避免开销。

我有一个看起来像这样的表:

drop table Data

create table Data
(
    Id BIGINT NOT NULL,
    Date BIGINT NOT NULL,
    Value BIGINT,
    constraint Cx primary key (Date, Id)
)

create nonclustered index Ix on Data (Id, Date)

表格永远不会更新。删除可以发生，但它们永远不应该与 SELECT 竞争，因为它们会影响表的另一端。插入是常规的，页面拆分到 (Id, Date) 索引非常常见。

我在标准 INSERT 和 SELECT 之间遇到了死锁情况，如下所示:

select top 1 Date, Value from Data where Id = @p0 order by Date desc

因为 INSERT 获取了 Cx (Date, Id; Value) 上的锁，然后是 Ix (Id, Date)，但是 SELECT 获取了 Ix (Id, Date) 上的锁，然后是 Cx (Date, Id; Value) .这是因为 SELECT 首先在 Ix 上查找，然后加入到 Cx 上的查找。

交换聚簇索引和非聚簇索引会打破这个循环，但这不是一个可接受的解决方案，因为它会引入其他(更复杂的)SELECT 的循环。

如果我在 SELECT 中添加 NOLOCK，在这种情况下它会出错吗？能否返回:

1. 不止一行，即使我要求的是 TOP 1？
2. 没有行，即使存在并已提交？
3. 最糟糕的是，一行不满足 WHERE 子句？

我已经在网上阅读了很多关于此的内容，但我所见过的重复计数过多或计数不足的异常(one、two)涉及扫描。这只涉及寻找。杰夫·阿特伍德 has a post关于使用 NOLOCK 产生了很好的讨论。我对 Rick Townsend 的评论特别感兴趣:

Secondly, if you read dirty data, therisk you run is of reading theentirely wrong row. For example, ifyour select reads an index to findyour row, then the update changes thelocation of the rows (e.g.: due to apage split or an update to theclustered index), when your selectgoes to read the actual data row, it'seither no longer there, or a differentrow altogether!

仅插入而不更新是否可能？如果是这样，那么我想即使我在仅插入表上进行搜索也可能很危险。

---

更新:

我想弄清楚 how snapshot isolation works .它似乎是基于行的，其中事务读取表(没有共享锁!)，找到它们感兴趣的行，然后查看它们是否需要从 tempdb 中的版本存储中获取该行的旧版本。

但在我的例子中，每一行都不会有一个以上的版本，所以版本存储似乎毫无意义。如果发现该行没有共享锁，这与仅使用 NOLOCK 有何不同？

Answer 1

使用 NOLOCK 或 READ UNCOMMITTED 意味着您放弃任何一致性保证。期间。

如果您需要一致性，请不要进行脏读。您的整个解释依赖于未记录的行为，这些行为可能会在未来的版本中发生变化，更糟糕的是，依赖于您希望查询的特定访问计划。查询优化器可以自由选择它认为合适的任何计划，并且您所做的任何假设都可能在生产中被打破。回到原点:如果您没有准备好面对后果，请不要进行脏读。

不确定这是否适用，不清楚您尝试通过查询/表实现的目标，但也许这篇文章可能有所帮助:Using tables as Queues .

已更新
如果 NOLOCK 读取会读取不一致的状态(例如，读取陈旧的非聚集索引键并将其追踪到聚集索引中缺失的行)，则快照读取会在版本存储中找到“缺失”的行。对于稳定数据，快照读取与非锁定读取相同。每当数据发生更改(未提交的更新)时，版本存储的魔力就会发挥作用，因为快照读取进入版本存储并找到“旧”值(稳定且一致)，而 nolock 读取将在其中失控并追逐指针啦啦乐园。