以前一直认为键范围锁定只是在序列化隔离级别中才会出现，但是从论坛的一篇帖子中看到Read-Committed隔离级别中竟然也出现了：
59:50. spid24s process id=process6463b88 taskpriority=0 logused=480 waitresource=KEY: 6:72057594065715200 (8500ea663c04) waittime=516
ownerId=773364767 transactionname=test lasttranstarted=2013-06-04T08:59:49.450
XDES=0x80092570 lockMode=RangeS-U schedulerid=22 kpid=2872 status=suspended
spid=57 sbid=0 ecid=0 priority=0 trancount=3
lastbatchstarted=2013-06-04T08:59:49.453 lastbatchcompleted=2013-06-04T08:59:49.450
isolationlevel=read committed (2) xactid=773364767 currentdb=6 lockTimeout=4294967295
clientoption1=671088672 clientoption2=128056
之后查到两片文章提到SQL Server在一定的条件下会隐式的提升隔离级别到序列化。
微软用级联删除的例子做了说明：
createtableFoo(FooIdintnotnullprimarykey)
createtableBar(FooIdintnotnull,BarIdintnotnull)
altertableBaraddconstraintPK_Barprimarykey (FooId,BarId)
altertableBaraddconstraintFK_Bar_Fooforeignkey (FooId)referencesFoo(FooId)ondeletecascade
insertintoFoovalues (1)insertintoBarvalues (1, 1)
settransactionisolationlevelreadcommitted
begintran
deletefromFoowhereFooId= 1
committran
删除的操作需要保持：
1.删除Foo 表的数据其实也要删除Bar表中相关联的数据
2.在语句结束的时候，外键约束还是有效的。
所以在read-committed隔离级别下，X locks一直持续到交易结束，但是不能避免在删除的同时其他人插入数据。所以需要SERIALIAZABLE隔离级别。
所以，对于类似的操作，不需要用户显示的使用serialization 隔离级别，SQL Server会自动将隔离级别升级从而阻塞其他操作插入数据从而影响外键约束。在这种情况下，SQL Server会使用键范围锁定.这种方法可以避免数据损坏。
SERIALIZABLE级别的锁会一直保持到交易结束，如果一个批次中有多条语句，可能需要一段时间释放这些锁。因为SQL Server知道使用了什么锁，并且什么时候释放才是安全的。
另外索引视图维护也是相同的情况。
更多资料可以参考：Read Committed isolation level, indexed views and locking behavior
Conor vs. Isolation Level Upgrade on UPDATE/DELETE Cascading RI
本文转自 lzf328 51CTO博客，原文链接:
