ReadUncommitted 事务创建锁答案

【问题标题】：ReadUncommitted transaction creating locksReadUncommitted 事务创建锁
【发布时间】：2020-11-30 09:54:54
【问题描述】：

我在 ReadUncommited 模式下使用 .NET 5.0 事务：

MyDbcontext.Database.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted)

我的理解是，在这种模式下，数据库上没有锁（当然，代价是用户可能会读取不是最新的记录）。

但我注意到，在提交或回滚此事务之前，我确实会获得锁。我可以在提交/回滚之前触发断点并在我的 MS SQL Studio 管理器中执行 SQL 请求时看到它。在事务提交或回滚之前，请求不会返回。

这是它应该工作的方式吗？如果是这样，有没有办法让我的交易完全没有锁定？我不介意阅读未提交的记录，但我仍然需要一个事务来确保所有数据库操作都运行或不运行。

【问题讨论】：

请分享minimal reproducible example。
But I notice that I DO get locks你是怎么得出这个结论的？
@mjwills ：我得出这个结论是因为我的选择 SQL 查询（从我的 MS SQL Studio 管理器在 VS 之外运行）在事务提交或回滚之前不会返回。
我们需要minimal reproducible example。
My understanding is that with this mode, there are no locks on the DB 这不是真的。例如，更新需要解锁。

【解决方案1】：

在读取未提交隔离级别下读取时，SQL Server 仍会请求架构稳定性锁。

此外，无论运行在何种隔离级别下，SQL Server 都会在写入时请求排他锁。

我建议您不要使用未提交的读取隔离级别，因为它会产生除未提交读取之外的其他问题，例如读取同一行两次或跳过读取一行。

我建议您使用已提交的快照或快照隔离级别，而不是未提交的读取。这些隔离级别在读取时不请求共享锁，同时保持重要的保证。

【讨论】：

我知道锁定是欺骗性触发器的结果。由于在这篇文章中解释这一切与我原来的帖子不同，我宁愿创建另一个帖子来阐明这种奇怪的行为。同时，我意识到切换到隔离级别 SNAPSHOT 正在解决问题，所以我会相信这个答案。谢谢耶稣。
如果有兴趣：stackoverflow.com/questions/65104045/…