sql-server - SQL Server中的锁序列

SQL Server锁定基于Transaction Processing: Concepts and Techniques中的概念。本书详细解释了如何获取锁，需要什么锁以及为什么事物必须如此。

Marc链接的资源是对该主题的良好报道，但细节分散，您需要知道在哪里查看。这是一本启动你的入门书：

事务隔离级别仅影响读锁定。在正常read committed下读取行时，会获取在读取后立即释放的S锁定。如果隔离级别提升到repeatable read，则保持S锁直到事务结束。在较高的serializable级range locks上放置而不是简单的行锁，并且它们一直保持到事务提交为止。快照模式的不同之处在于它们不一定会影响锁的类型，而是从版本存储中检索读取：行的源。

锁定顺序/层次结构始终相同：

在任何DML操作开始时，在元数据上放置Sch-S锁。 DDL操作需要Sch-M锁并因此发生冲突，因此DML可以确保其运行的模式的“稳定性”（对象模式，而不是数据库模式......）。
行的锁层次结构路径是table-page-row。引擎决定的实际粒度为dynamic。通常是行。
无论粒度如何，实际锁定资源的路径都受intent locks保护。 IE浏览器。要对S锁定一行，读者必须在表和页面上获取IS锁定。要S锁定页面，它需要在桌面上进行IS锁定。
单个分区操作在扫描中获取超过5000个锁定可能会触发lock escalation。升级始终是尝试（即，如果失败则永远不会阻止）。实践中的升级总是从行级锁定到表（2008年的分区）级别锁定。

锁定提示永远不会更改锁定的顺序，它们只能更改：

锁的类型（当需要S锁时，U型锁或X锁）
粒度（强制表，或页面或行）
持续时间（持有S锁）
阻塞行为（readpast跳过不兼容的行）。

我没有太多关于插入/更新/删除的内容，因为它们非常无趣：它们需要X锁，就是这样。关于它的唯一有趣的事情是更新的工作方式，因为它首先获得一个U锁，后来转换为X锁。需要此行为来利用允许挂起S锁在更新进行之前耗尽的U-lock asymmetry。

有了这个，我希望你能找到链接的文章和书籍中遗漏的所有细节。

SQL Server中的锁序列

2 个答案: