查询计划器是否自行决定何时采用更新锁和共享锁？答案

【问题标题】：Does query planner decide on its own when to take Update lock vs Shared lock?查询计划器是否自行决定何时采用更新锁和共享锁？
【发布时间】：2019-07-23 21:34:40
【问题描述】：

我在official documentation、博客和stackoverflow 中阅读了有关更新锁的信息。我看到使用 UPDLOCK 提示指示查询计划程序获取更新锁的查询示例（通常这样做是为了避免可重复读取或可序列化隔离级别中的死锁）。

是否需要始终手动指定 UPDLOCK 提示，或者是否存在查询计划程序自动决定需要更新锁而不是共享锁的情况？
如果是，是否有一些简单的示例，查询规划器会自动决定对 Shared 进行更新锁定？

【问题讨论】：

标签： sql-server tsql locking

【解决方案1】：

UpdLock 查询提示允许开发人员跨多个 DML 语句更改默认锁定行为。查询分析器没有理由将锁从一条语句扩展到另一条语句，例如直觉上 select 语句中的数据可能会在随后的 update 语句中被修改，作为保留茶座的一部分。

【讨论】：

谢谢。因此，听起来好像通过支持更新锁，sql server 允许用户通过支持接受提示的方式来避免死锁。但是，如果没有用户提供提示（甚至没有提示），数据库 仍然可以 陷入死锁。（并选择一个受害者摆脱它）。所以它不会自动使数据库死锁免费，但它提供了减少它的方法。听起来对吗？
@Turbo 没错。使用锁定提示在仅执行单个 DML 语句和执行隔离级别为serializable 的事务之间增加了一个粒度级别。您可以添加最小化锁定和简化事务的语义。在某些情况下，您可以仔细安排操作，以免发生死锁，在其他情况下，您可以尽量减少死锁。（至少在一些运行临时查询的有用用户搞砸之前。）您还可以使用nowait 提示实现拒绝等待锁定并立即失败的“实时”进程。