SQL Server乐观锁定和悲观锁定实例

举报
wh_bn 发表于 2021/12/15 23:24:06 2021/12/15
2.2k+ 0 0
【摘要】   【引自老陈的博客】 在实际的多用户并发访问的生产环境里边，我们经常要尽可能的保持数据的一致性。而其中最典型的例子就是我们从表里边读取数据，检查验证后对数据进行修改，然后写回到数据库中。在读取和写入的过程中，如果在多用户并发的环境里边，其他用户已经把你要修改的数据进行了修改是非常有可能发生的情况，这样就造成了数据的不一致...

【引自老陈的博客】

在实际的多用户并发访问的生产环境里边，我们经常要尽可能的保持数据的一致性。而其中最典型的例子就是我们从表里边读取数据，检查验证后对数据进行修改，然后写回到数据库中。在读取和写入的过程中，如果在多用户并发的环境里边，其他用户已经把你要修改的数据进行了修改是非常有可能发生的情况，这样就造成了数据的不一致性。解决这样的办法，SQL SERVER提出了乐观锁定和悲观锁定的概念，下边我以一个实例来说明如何使用乐观锁定和悲观锁定来解决这样的问题。

/*建立测试表:Card，代表一个真实的卡库，供用户注册。用户要从里边选出一个未使用的卡，也就是F_Flag=0的卡，给用户注册：更新F_Name，F_Time，F_Flag字段。如果出现两个用户同时更新一张卡的情况，是不能容忍的，也就是我们所说的数据不一致行。*/

create table Card(F_CardNO varchar(20),F_Name varchar(20),F_Flag bit,F_Time datetime)
Go
insert Card(F_CardNo,F_Flag) select '1111-1111',0
insert Card(F_CardNo,F_Flag) select '1111-1112',0
insert Card(F_CardNo,F_Flag) select '1111-1113',0
insert Card(F_CardNo,F_Flag) select '1111-1114',0
insert Card(F_CardNo,F_Flag) select '1111-1115',0
insert Card(F_CardNo,F_Flag) select '1111-1116',0
insert Card(F_CardNo,F_Flag) select '1111-1117',0
insert Card(F_CardNo,F_Flag) select '1111-1118',0
insert Card(F_CardNo,F_Flag) select '1111-1119',0
insert Card(F_CardNo,F_Flag) select '1111-1110',0
Go

--  下边是我们经常使用的更新方案如下：

declare @CardNo varchar(20)
Begin Tran--  选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card    where F_Flag=0

--  延迟50秒，模拟并发访问.
waitfor delay '000:00:50'--  把刚才选择出来的卡进行注册.update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNocommit

问题：如果我们在同一窗口执行同一段代码，但是去掉了waitfor delay子句。两边执行完毕后，我们发现尽管执行了两次注册，但是只注册了一张卡，也就是两个人注册了同一张卡。

悲观锁定解决方案

--  我们只要对上边的代码做微小的改变就可以实现悲观的锁定。

declare @CardNo varchar(20)
Begin Tran--  选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card   with (UPDLOCK)  where F_Flag=0

--  延迟50秒，模拟并发访问.
waitfor delay '000:00:50'--  把刚才选择出来的卡进行注册.update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNocommit

注意其中的区别了吗?with(updlock)，是的，我们在查询的时候使用了with(UPDLOCK)选项，在查询记录的时候我们就对记录加上了更新锁，表示我们即将对次记录进行更新。注意更新锁和共享锁是不冲突的，也就是其他用户还可以查询此表的内容，但是和更新锁和排它锁是冲突的。所以其他的更新用户就会阻塞。如果我们在另外一个窗口执行此代码，同样不加waifor delay子句。两边执行完毕后，我们发现成功的注册了两张卡。可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候，其他更新用户必须排队等待，即使那个用户更新的不是同一条记录。

乐观锁定解决方案

--  首先我们在Card表里边加上一列F_TimeStamp 列，该列是varbinary(8)类型。但是在更新的时候这个值会自动增长。

alter table Card add  F_TimeStamp timestamp not null--  悲观锁定
declare @CardNo varchar(20)
declare @timestamp varbinary(8)
declare @rowcount intBegin Tran--  取得卡号和原始的时间戳值
select top 1 @CardNo=F_CardNo,
@timestamp=F_TimeStamp
from Card
where F_Flag=0

--  延迟50秒，模拟并发访问.
waitfor delay '000:00:50'--  注册卡,但是要比较时间戳是否发生了变化.如果没有发生变化.更新成功.如果发生变化,更新失败.update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNo and F_TimeStamp=@timestamp
set @rowcount=@@rowcount
if @rowcount=1
begin
print '更新成功!'
commit
end
else if @rowcount=0
begin
if exists(select 1 from Card where F_CardNo=@CardNo)
begin
print '此卡已经被另外一个用户注册！'
rollback tran
end
else
begin
print '并不存在此卡!'
rollback tran
end
end

在另外一个窗口里边执行没有waitfor的代码，注册成功后，返回原来的窗口，我们就会发现到时间后它显示的提示是此卡以被另外一个用户注册的提示。很明显，这样我们也可以避免两个用户同时注册一张卡的现象的出现。同时，使用这种方法的另外一个好处是没有使用更新锁，这样增加的系统的并发处理能力。

上边我详细介绍了乐观锁定和悲观锁定的使用方法，在实际生产环境里边，如果并发量不大，我们完全可以使用悲观锁定的方法，因为这种方法使用起来非常方便和简单。但是如果系统的并发非常大的话，悲观锁定会带来非常大的性能问题，所以我们就要选择乐观锁定的方法。

如果大家发现文章里边有什么错误的地方，请及时提醒我，也欢迎有兴趣的一起研究讨论。

文章来源: blog.csdn.net，作者：fengda2870，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/fengda2870/article/details/3152295

【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
SQL SQL Server
  • 点赞
  • 收藏
  • 关注作者

作者其他文章

评论（0）

抱歉，系统识别当前为高风险访问，暂不支持该操作

    全部回复

    上滑加载中

    设置昵称

    在此一键设置昵称，即可参与社区互动！

    *长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

    *长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

    确认 取消

    加入云驻计划，成为创作者

    • 华为云周边好礼
    • 免费体验产品
    • 特殊身份标识
    • 线下官方门票
    • 内部专家零距离
    • 与10000+优质创作者共同成长
    立即加入