锁层级（Lock Hierarchy）
2个星期前，当我们开始讨论悲观并发模式（pessimistic concurrency）时，我告诉你SQLServer在记录层会获取共享锁（Shared Locks）和排它锁（Exclusive Locks）。遗憾的是，这不是全部事实。完整事实是SQL Server会在不同粒度（granularities）获得锁，例如数据库，不同页，最后在记录层。SQL Server实现整个所层级（lock hierarchy），如下图所示：
一旦你使用一个数据库，你的会话会在数据库上获得一个共享锁（Shared Lock）。那个共享锁是需要的，因此没有其他人可以删除数据库，或还原数据库备份。这些操作会被阻塞，因为你打开的会话。SQL Server不但在行层上有共享锁和排它锁，SQL Server也在表和页层使用所谓的意向锁（Intent Locks）。
- 在行层有共享锁（Shared Locks），在表和页上拿到意向共享锁（intent shared lock（IS））。
- 在行层有排它锁（Exclusive Locks），在表和页上拿到意向排它锁（intent exclusive lock（IX））。
意向锁（Intent Locks）用来作为1个信号，表示在锁层级（lock hierarchy）里（很可能）有1个不兼容的锁在低一层已获得。意向锁是关系数据库主要性能调优。没有它们的话，锁管理器需要在低1层完全进入列表，来决定高1层的锁是否可以获取。如果你在表层有一个意向排它锁（IX），你就不能在表层获得排它锁（X），因为有些记录在表本身里已经是排它锁（X）：在表层获得排它锁（X）会阻塞，因为在表上已经有意向排它锁（IX）。
遗憾的是这个多粒度锁并不是免费的：在SQL Server里每个锁需要96 bytes，因此会消耗一些内存，SQL Server必须保证没有查询使用太多的内存空间，不然的话内存会被耗尽。这就是为什么会有锁升级（lock escalations）的存在。
锁升级（Lock Escalations）
假设下列情景：你更新散布在20万个数据页上的1百万条记录。在那个情况下，你需要在记录本身获得1百万个排它锁（X），在不同页上获得20万个意向排它锁（IX），在表本身上获得1个意向排它锁（IX），你的查询合计需要获得1200001，在锁管理器需要近110M的锁空间——就只对这个简单查询。依据内存占用这个方法非常危险。因此你在一层一旦获得超过5000个锁，SQL Server就会触发锁升级（Lock Escalations）——例如在记录层。在那个情况下，SQL Server升级你个体细密度行锁为1个粗颗粒的表锁：
- 个体X锁升级为1个表的X锁
- 个体S锁升级为1个表的S锁
下图演示了锁升级发生前后的锁保持情况：
通过锁升级内存占用肯定会下降——但这也会影响你数据库的并发！在表上的排它锁（X）意味着没有其他人可以从你的表读写，在表层上的共享锁（S）意味着你的表是只读的，没有人可以写它！你数据库的吞吐量只会下降！
当你在1个层获得超过5000个锁，SQL Server就会触发锁升级。这是系统硬码限定，不同通过任何配置选项修改。自SQL Server 2008开始，你可以通过如下代码，控制通过ALTER TABLE DDL语句的锁升级：
1 ALTER TABLE MyTableName 2 SET 3 ( 4 LOCK_ESCALATION = TABLE -- or AUTO or DISABLE 5 ) 6 GO
默认情况，SQL Server总是升级到表级别（Table选项）。如果你设置升级选项为AUTO，当你的表是分区的话，SQL Server可以升级到分区级别。但对这个选项，你要非常仔细，因为如果你用错误的顺序访问分区，它会导致死锁。使用DISABLE选项，对表你停用了锁升级——这会带来刚才提到的所有各个副作用（内存消耗）。现在的问题是，你如何高效修改或删除5000条记录而不触发锁升级？
- 逐步更新/删除少于5000条记录（例如在WHILE循环里）
- 如果表分区的话，使用分区交换
- 临时停用锁升级，但要注意同时的内存耗用
小结
锁升级（Lock Escalations）是SQL Server提供的安全保障。它们为什么存在有个好理由，但当升级发生时，这个会引入更少并发的副作用。因此当你在写一次处理超过5000条记录的代码时要非常仔细。或许你可以逐步处理这些记录，而不是用1个大的UPDATE/DELETE语句。如果你想了解更多锁升级信息，可以看下我以前写一篇文章《锁升级》。
本文转自Woodytu博客园博客，原文链接：http://www.cnblogs.com/woodytu/p/4705602.html，如需转载请自行联系原作者
