浅谈 SQL 中的锁（四）如何检查重复用户

最新推荐文章于 2022-08-17 16:13:28 发布

闭包客

最新推荐文章于 2022-08-17 16:13:28 发布

阅读量558

点赞数

分类专栏：浅谈 SQL 中的锁

本文链接：https://blog.csdn.net/closurer/article/details/54379863

版权

浅谈 SQL 中的锁专栏收录该内容

7 篇文章 0 订阅

订阅专栏

本文讨论了在SQL Server中使用Serializable隔离级别解决并发注册用户时出现的问题。通过设置事务隔离级别为Serializable并使用holdlock提示，可以有效防止幻读，确保事务的一致性和互斥性。

摘要由CSDN通过智能技术生成

上一节 http://blog.csdn.net/closurer/article/details/54342831 说了一个注册用户的事务没有互斥，导致注册用户失败的问题。

也说了解决方法就是使用 serializable 隔离级别去执行事务：

--开始事务
begin transaction

--设置串行式事务
set transaction isolation level serializable

--检查用户用户存在
if(not exists(select * from app_user(updlock) where mobile = '13800002222'))
begin
	--延长处理时间
	waitfor delay '0:00:10'

	--添加用户
	insert app_user values('13800002222')
end

--提交事务
commit transaction

--查看处理结果
select * from app_user

只是在原来的脚本加了一句：

--设置串行式事务
set transaction isolation level serializable

这个注册用户的事务就会互斥了。

原来之所以会注册失败，是因为 13800002222 这个用户在表中是不存在的，所以并没有锁定成功。

serializable 隔离级别与其他三个隔离级别不同的是，它使用的是范围锁，即使查询的数据在表中不存在，也会锁定它所在的范围。至于使用的是页面锁，还是表级锁，这个我并没有去深究过，可能不同的数据库产品有不同的实现。不过对任何的事务数据库产品来说，只要使用了 serializable，是一定可以锁定所查询数据的范围的。这是阻止【幻读】必要条件。

在 SQL Server 中，还可以使用 holdlock 表提示去对事务中的某一个查询使用 serializable，更加的灵活、简洁，不过在其他产品中不支持，比如 MySQL