锁升级（Lock Escalations）——它们常常发生么？

前段时间，我写了一些SQL Server里锁升级的基础知识，还有它是如何影响执行计划的。今天，我想进一步谈下锁升级：

锁升级何时发生？

一般在SQL Server里若是在SQL语句里你请求的行数超过5000（SELECT，INSERT，UPDATE，DELETE）会发生锁升级。例如当你再可重复读隔离级别（Repeatable Read Isolation Level）里，从表你读超过5000行数据，锁升级就会被SQL Server触发。

当你对超过5000行的数据运行UPDATE和DELETE语句，也会触发锁升级。做为反作用，最终你有一个共享（S）或排它（X）表锁。这确定会伤及你的并发，下降性能和你工做负载的吞吐量。

“阻塞”锁升级

锁升级的整个想法听起来很简单，但会有大影响和反作用：若是你不能得到共享或排它表锁会发生什么，由于其余人在表上得到了不兼容的锁？在这个状况下，锁升级应该阻塞么？但愿不是......

所以咱们来构建一个简单的例子，在这里咱们尝试重现这个状况来看下载这个特定状况下，SQL Server如何反应。下列查询在Person.Person表里汇集索引里的最后一行请求一个X锁。

-- This transaction locks the last row in the Clustered Index of the 
-- table Person.Person
BEGIN TRANSACTION

UPDATE Person.Person
SET LastName = '...'
WHERE BusinessEntityID = 20777

这也意味着SQL Server在对应的页和表自己会得到意向排它锁（Intent Exclusive Lock (IX)）。如今假设你再可重复读隔离级别运行SELECT语句，而且你请求超过5000行级别锁。在这个状况下，SQL Server须要触发锁升级，升级各个共享锁到表级别的共享锁。

但在咱们的状况下不能在表级别得到共享锁，由于共享锁已经已经为咱们UPDATE语句授予的IX锁不兼容。这个锁层级是有道理的，由于其余人已经造门锁层级里得到了不兼容的X锁。所以咱们从Person.Person表的汇集索引SELECT前6000行数据。

-- This statement would trigger a Lock Escalation
-- Run this in a different session...
BEGIN TRANSACTION

SELECT TOP(6000) * FROM Person.Person WITH (HOLDLOCK)

幸运的是，这个SELECT语句没有阻塞！还不错！在咱们的例子里，SQL Server尝试进行锁升级，但放弃了，由于在表层级上有一个不兼容的锁（IX）。若是锁升级阻塞的话，状况会更加糟糕，由于这会无端下降并行查询的并发！

小结：

在SQL Server里锁升级很是重要，由于它们帮助SQL Server节约里在锁管理器里的哈希表空间。但锁升级只被SQL Server“尝试”。若是SQL Server不能进行锁升级，由于在表层级有不兼容的锁，什么也不会发生。锁升级不能占用空间，触发锁升级的SQL语句也不会阻塞。

但愿这个特定场景能够帮你更好的理解SQL Server里的锁升级行为。

原文连接：

https://www.sqlpassion.at/archive/2016/05/09/lock-escalations-do-they-always-happen/