SQL Server NOLOCK 提示会返回部分写入的行吗?
首先,我不是问是否应该使用 NOLOCK。让我们过去吧。
我想问题归结为sql server如何写入数据?是一次写入一整行还是一次写入一列?
我这样问是因为正在考虑 NOLOCK 提示。只要返回(或不返回)整行,脏读就可以。部分写入的行是不可接受的。
First of all I'm not asking if NOLOCK should or should not be used. Let's get past that.
I guess the question comes down to how sql server writes data? Is an entire row written at once or does it write it a column at a time?
I'm asking because the NOLOCK hint is being considered. A dirty read is fine as long as the entire row is returned (or not returned). Partially written rows are not acceptable.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不会。插入、更新和删除等数据修改操作受低级物理保护 闩锁。所有数据访问操作,包括无锁 SELECT,都必须遵守锁存协议。结果是任何读者都看不到部分写入。
No. Data modification operations like inserts, updates and deletes are protected by low level physical Latches. All data access operations, including lock-free SELECT, are obliged to conform to the latching protocol. The result is that partial writes are never seen by any reader.
与其他两个答案中所说的相反:您可能会被撕裂。
一种情况是当您有键查找时,因此非聚集索引具有旧的数据的版本和聚集索引具有新版本。
第二种情况是 LOB 列,因此任何
varchar(max)
nvarchar(max)
varbinary(max)
xml
text
ntext
image
列。由于锁存(这与锁定分开并且无法禁用),单个页面无法同时更新,但可以同时写入多个页面。这对于行内数据来说不是问题,因为一行不能跨越多个页面,它仅在 LOB 数据上体现,即使它正好适合一页,因为它位于行外。
此链接:
创建脚本
会话 1
会话 2
另请注意,
NOLOCK
还有许多其他效果,尤其是您可以读取同一行两次,或者根本不读取,并且在不同的引用中会有不同的情况同一张表的。这可能会影响需要唯一连接的查询,这可能会使连接增加一倍。Contrary to what is said in the other two answers: You can get torn reads.
One case is when you have a Key Lookup, so the non-clustered index has the old version of the data and the clustered index has the new version.
A second case is on LOB columns, so any
varchar(max)
nvarchar(max)
varbinary(max)
xml
text
ntext
image
columns.A single page cannot be updated simultaneously, due to latching (this is separate from locking and cannot be disabled), but multiple pages can be written simultaneously. This is not an issue with in-row data, because a row cannot span multiple pages, it only manifests on LOB data, even if it fits on exactly one page, because it lives off-row.
This is demonstrated in this link:
Creation script
Session 1
Session 2
Note also that there are many other effects of
NOLOCK
, not least that you can read the same row twice, or not at all, and differently in different references of the same table. This might affect queries which expect a unique join, which could double up your joins.