键范围锁定（Key-Rang Lock）是不是只在序列化级别中出现的问题

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

微软用级联删除的例子做了说明：

create table Foo(FooId int not nullprimary key)

create tableBar(FooIdint not null, BarId intnot null)

alter tableBar add constraint PK_Bar primary key (FooId,BarId)

alter tableBar add constraint FK_Bar_Foo foreign key (FooId)references Foo(FooId) on delete cascade

insert intoFoo values (1) insert into Bar values (1, 1)

set transactionisolation level read committed

begin tran

delete fromFoo where FooId = 1

commit tran

删除的操作需要保持：

1. 删除Foo 表的数据其实也要删除Bar表中相关联的数据

2. 在语句结束的时候，外键约束还是有效的。

所以在read-committed隔离级别下，X locks一直持续到交易结束，但是不能避免在删除的同时其他人插入数据。所以需要SERIALIAZABLE隔离级别。

所以，对于类似的操作，不需要用户显示的使用serialization隔离级别，SQL Server会自动将隔离级别升级从而阻塞其他操作插入数据从而影响外键约束。在这种情况下，SQL Server会使用键范围锁定.这种方法可以避免数据损坏。

SERIALIZABLE级别的锁会一直保持到交易结束，如果一个批次中有多条语句，可能需要一段时间释放这些锁。因为SQL Server知道使用了什么锁，并且什么时候释放才是安全的。

另外索引视图维护也是相同的情况。