关于SQL Sserver ROWLOCK锁的一个误解

关于SQL Server锁类型,我就不列举了,大家可以通过MSDN来了解。
http://msdn.microsoft.com/zh-cn/library/ms187373.aspx

今天我就来讲一个十分有意思的事情,是在我进行并发测试时遇到的。

众所周知,在一段涉及卖票逻辑的程序中,在卖票操作时先要查询下是否有余票,有的话这要对票加锁,然后扣票和在用户记录表添加买票记录。
Two table : [Ticket] [table_user]

Begin Transaction
select top 1* from [Ticket] with (XLOCK,ROWLOCK) where Status=1;
update [Ticket] set [Status]=2,…where…
update [table_user] set …….
End Transaction

模拟并发请求时,会发现这段代码实际执行时总是表现为表锁的现象。那么是因为在select的时候where条件没有使用primary key的缘故吗?
select * from [Ticket] with (XLOCK,ROWLOCK) where id in (select top 1 id from [Ticket] where Status=1);
仍旧不行。
Why? Why? Why? …
通过观察表现每次请求时,数据库执行这段SQL总是表现为表锁,而且查询出来的数据都是同样的一行。仔细分析,原来问题出在SQL语句上:
SQL SEVER在使用行级排他锁select时会锁住了一条记录,而且此时其他的请求仍旧能够查询到此条记录,但是会在这里阻塞。所以在模拟并发的时候,多个进程都是查询到同一条记录上,于是在测试中总是表现出表被被锁住现象。
最后我的解决方法是在select时加入一定的随机规则,尽量让多个进程不要查询在一条记录上。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*