每次问题都通过SQL Server中的锁和锁阻塞来解释：在SQL Server中，为什么需要更新锁在解释特定需求的原因之前，首先，我想介绍一下更新锁（更新（U）锁）是如何获得的，根据它的兼容性，锁本身是如何响应的

一般来说，当执行UPDATE语句时，SQLServer使用更新锁（更新锁）。如果您查看相应的执行计划，您将看到它包含3个部分：

读取数据

计算新值

写数据



在查询计划的第一部分，SQL Server开始读取数据进行修改和获取更新锁的每个记录（更新锁）。在查询计划的最后第三个部分，这些更新锁（更新锁）转换为排他锁（互斥（X））时数据修改。从这个问题产生的方法都是一样的：在第一阶段，为什么SQL服务器获取更新锁（更新锁）代替共享锁（共享锁（S））。通常，当你读到的数据通过一个SELECT语句，共享锁（S）是不够的。为什么在当前更新的查询计划的区别让我们详细分析一下。

避免死锁（死锁避免）

首先，在更新的查询计划，更新锁用于防止死锁的情况。假设在计划的第一阶段，有一些更新的查询计划获得一个共享锁（共享锁（S）），然后在查询计划的第三阶段，当数据最后一次修改，共享锁（共享锁）成排它锁（互斥的长相），会发生什么事：

第一个查询不能将共享锁转换为行锁，因为第二个查询已经获得了共享锁。

第二个查询不能将共享锁转换为行锁，因为第一个查询已经获得了共享锁。





这是一个主要的原因，关系数据库引擎引入了一个更新锁避免特定死锁的情况。更新锁只兼容一个共享锁，但这是不是另一个更新或排他锁兼容。因此，死锁的情况是可以避免的，和2的更新查询计划不能同时运行。在查询的第一阶段，第二查询将等到获得更新锁，系统未公开的研究也表明，如何避免这种明显的死锁。系统不使用任何更新锁来避免死锁。

并发性的提升

没有更新锁在第一阶段获得的，这也是一个可见的选项来获得行锁直接在这个阶段。这将解决死锁问题，因为排斥锁与其他不兼容。但这种方法的问题是并发性是因为没有其他选择查询，可以阅读是目前在一排锁数据的限制。所以你需要更新锁，因为这种锁是与传统的共享锁兼容。这样，其他选择查询可以读取数据，只要更新锁尚未转化为行锁。作为一个副作用，这将提高查询的并发，我们同时运行。

在以前的关系的学者，更新锁被称为非对称锁。在更新锁的情况下，更新锁和共享锁兼容，但相反的是：共享锁和更新锁兼容。但SQL Server不实现一个共享锁是一种非对称锁。更新锁对称（对称），这意味着更新锁和共享锁是相互兼容的，这提供了整个系统的并发因为阻塞情况不在2锁式钥匙了。

总结

在今天的文章中，我向您介绍一个共享锁，以及为什么需要共享一个锁。正如您在关系数据库中看到的那样，强烈地需要更新锁，否则将带来死锁和减少并发性。我希望您对现在的更新锁有很好的理解，以及它们如何在SQL Server中使用。

以上是本文的全部内容，希望大家能喜欢。