在SQLServer里为什么我们需要更新锁_sqlserver更新锁资源-CSDN下载

68 浏览量 2021-01-19 22:05:22 上传评论收藏 132KB PDF 举报

资源推荐

资源详情

资源评论

在在SQL Server里为什么我们需要更新锁里为什么我们需要更新锁

　　我想讲解一个特别的问题，在我每次讲解SQL Server里的锁和阻塞（Locking & Blocking）都会碰到的问题：在SQL

Server里，为什么我们需要更新锁？在我们讲解具体需要的原因前，首先我想给你介绍下当更新锁（Update（U）Lock）获得

时，根据它的兼容性锁本身是如何应对的。

　　一般来说，当执行UPDATE语句时，SQL Server会用到更新锁（Update Lock）。如果你查看对应的执行计划，你会看到

它包含3个部分

　　读取数据

　　计算新值

　　写入数据

　　在查询计划的第1部分，SQL Server初始读取要修改的数据，在各个记录上会获得更新锁（Update Locks）。在查询计划

的后第3部分，当数据被修改时，这些更新锁（Update Locks）转化为排它锁（Exclusive（X））。用这个方法产生的问题都

是一样的：在第1个阶段，SQL Server为什么要获得更新锁（Update Locks），而不是共享锁（Shared（S） Locks）。平常

当你通过SELECT语句读取数据，共享锁（Shared（S） Locks）已经够用了。现在的更新查询计划为什么有这个区别？我们

来详细分析下。

　　回避死锁（Deadlock Avoidance）

　　首先在更新查询计划里，更新锁用来避免死锁情形。假设在计划的第1阶段，有多个更新查询计划获得共享锁

（Shared（S）Locks），然后在查询计划的第3阶段，当数据后被修改时，这些共享锁（Shared Locks）转化为排它锁

（Exclusive Loks），会发生什么：

　　第1个查询不能转化共享锁为排它锁，因为第2个查询已经获得了共享锁。

　　第2个查询不能转化共享锁为排它锁，因为第1个查询已经获得了共享锁。

　　这是其中一个主要原因，为什么关系数据库引擎引入更新锁来实现避免特定的死锁情形。一个更新锁只与一个共享锁兼

容，但不与另一个更新或排它锁兼容。因此死锁情形可以被避免，应为2个更新查询计划不可能同时并发运行。在查询的第1

阶段，第2个查询会一直等到获得更新锁。System R的一个未公开研究也展示如何避免这类显著的死锁。System R不使用任

何更新锁来实现避免死锁。

　　提升的并发

　　在第1阶段不获得更新锁，在这个阶段直接获得排它锁也是可见选项。这会克服死锁问题，因为排它锁与另一个排它锁不

兼容。但这个方法的问题是并发受限制，因为同时没有其他的SELECT查询可以读取当前有排它锁的数据。因此需要更新锁，

因为这个特定锁与传统的共享锁兼容。这样的话其他的SELECT查询可以读取数据，只要这个更新锁还没转化为排它锁。作为

副作用，这会提高我们并发运行查询的并发性。

　　在以前关系学术上，更新锁是所谓的非对称锁（Asymmetric Lock）。在更新锁的上下文里，这个更新锁与共享锁兼容，

但反之不是：共享锁与更新锁不兼容。但SQL Server并不把共享锁作为非对称锁实现。更新锁是个对称（symmetric）的，是

说更新锁和共享锁是彼此双向兼容的。这会提供系统的整体并发，因为在2个锁类型键不会引入阻塞情形。

　　小结

　　在的文章里我给你介绍了共享锁，还有为什么需要共享锁。如你所见在关系数据库，是强烈需要更新锁的，因为不然的会

带来死锁并降低并发。我希望现在你已经很好的理解了更新锁，还有在SQL Server里它们是如何使用的。

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余0页未读，立即下载

内容反馈

weixin_38600460

粉丝: 5

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip