锁升级什么时候发生？
通常在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里的锁升级行为。
本文转自Woodytu博客园博客，原文链接：http://www.cnblogs.com/woodytu/p/5488602.html，如需转载请自行联系原作者
