关于sqlserver updlock的疑问

[被风吹过的]

经过本地测试 发现无论表的主键是一个 还是 复合主键 想给检索出来的row加锁时，都会锁到条件以外的row。
查了一些资料 说是跟表的索引有关系，加了索引后 也还是会有这样的问题，where条件目前只有主键项目
各位大佬 该怎么破？
select top 1 * from 【table】with(rowlock,updlock) where key1='xxx' and key2='yyyyy'

[卖水果的net]

where 条件中，有主键列吗 ？

[薛定谔的DBA]

主键 是聚集索引吗？？是否聚集索引锁定的内容不一样，因为你用星号。 另： 对于聚集索引和非聚集索引，正常查询的时候（不用updlock），肯定加行锁，同时会在这个行所在的数据页加一个意向锁，其他查询不影响。如果其他操作有更新这些行的，保证只能有一个更新锁访问（如你用updlock查询，也类似这操作 update…where ）。更新锁很快会升级为排他锁，同时在整个数据页页加意向更新，其他需要更新锁的就不能占用了，只能等前面的完成才能到下一个访问。 所以你对行加了更新锁，其实整个数据页也有意向更新锁，这个数据页的其他行当然也不能访问了。 附： 一般查询如果数据比较多，一次性查询记录大于6k或5k行，行锁就会升级为表锁（行锁太多耗性能），锁粒度变大了，对于其他都会有影响。如果强制用 rowlock，那么即使你查询几万行，那也用行锁而不升级为页锁或表锁，那锁开销就很大。

[被风吹过的]

引用 1 楼 wmxcn2000 的回复:

where 条件中，有主键列吗 ？

where 条件里面的key1和key2都是表的主键 也就是永远只能查询出来一条数据。

[被风吹过的]

引用 2 楼 kk185800961 的回复:

主键 是聚集索引吗？？是否聚集索引锁定的内容不一样，因为你用星号。 另： 对于聚集索引和非聚集索引，正常查询的时候（不用updlock），肯定加行锁，同时会在这个行所在的数据页加一个意向锁，其他查询不影响。如果其他操作有更新这些行的，保证只能有一个更新锁访问（如你用updlock查询，也类似这操作 update…where ）。更新锁很快会升级为排他锁，同时在整个数据页页加意向更新，其他需要更新锁的就不能占用了，只能等前面的完成才能到下一个访问。 所以你对行加了更新锁，其实整个数据页也有意向更新锁，这个数据页的其他行当然也不能访问了。 附： 一般查询如果数据比较多，一次性查询记录大于6k或5k行，行锁就会升级为表锁（行锁太多耗性能），锁粒度变大了，对于其他都会有影响。如果强制用 rowlock，那么即使你查询几万行，那也用行锁而不升级为页锁或表锁，那锁开销就很大。

谢谢回答。目前的where条件里面都是主键项目，所以只会检索出来一条数据，用updlock不会有性能方面的问题。就是现在其他行也被锁到，郁闷中。。。 如果使用updlick 这个该怎么解决呢？

[被风吹过的]

主键 是聚集索引 现在的需求是 即需要锁定这条数据而不影响其它数据 又要在加锁的时候判断这条数据是否被锁 如果像下面这样使用holdlock锁 则不存在锁其他行的情况 但是可以多次执行下面这句话 只能用update语句做更新处理去判断该数据是否被锁 但报的是超时的错误 需求等很长时间 select * from 【table】with（holdlock）where key1= xxxx and key2=xxxx 如果用updlock 则该条数据如果被锁 则会马上报1222错误 可以达到判断锁存在的需求 但是会锁其他行数据 所以。。。有没有更好的方法呢？

[薛定谔的DBA]

聚集索引是两个字段组合（key1，key2）吗？如果是，只查询的话是算最快了，一般不需要加任何锁。 锁是内部行为判断的，我们操作不需要去判断，只要控制好锁的粒度（键/行锁、页锁、表锁等）和锁的类型（共享、更新、排他、意向等）。锁的粒度，主要看访问的数据量及创建有效的索引去控制； 锁的类型，主要看我们操作说明，查询就共享锁，更新就共享锁+更新锁+排它锁，意向锁都会有。 我们也可以强制锁粒度和类型，如你写的sql（rowlock,updlock，holdlock），为什么 holdlock 不锁定？正常的查询，默认就是共享锁，查询结束就释放。你加了 holdlock ，也只是让这个查询保持共享锁，直到事务结束释放。和不加是一样的，正常查询也是这样！ 共享锁不影响查询！！ 查询的这行数据，所在的数据页的其他行数据都能访问。 使用 updlock 就不一样 ，更新锁只能有一个能访问，你并发执行，只能等前面查询完了才到下一个，所以有些堵塞。

[xiaoxiangqing]

这个不是那么精确