浅谈 SQL 中的锁(三)重复用户问题

拿 Web 项目中常见的注册用户场景做例子:

--测试用户表
create table app_user
(
	mobile varchar(11) primary key
)

--添加测试数据
delete app_user
insert app_user values('13800001111')


现在新注册一个手机号为 13800002222 的用户:

--开始事务
begin transaction

--检查用户是否存在
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


和上一节  http://bibaoke.com/post/24  相似,【检查用户是否存在】、【添加新用户】两个操作写在同一个事务中,第一个操作放置更新锁。

先执行这个语句,然后在 10秒钟内,在另外一个连接中执行同样的语句,模拟并发操作。

执行完毕后,第一个连接结果如下:

第二个连接发生了一个异常:

因为表中已经存在重复键,所以 insert 语句没有执行,数据仍然是一致的,用户 13800002222 在表中只有一个。

数据一致,说明这个异常并不严重,因为它并没有为系统产生重复的用户。如果你在 Web 服务器处理了这个异常,那么会返回注册不成功的消息给用户,如果没有处理,会显示错误页。

为什么两个事务没有互相隔离,从而使第二个事务试图插入一个重复键呢?

这是因为更新锁锁定的数据范围不够,与书本上所谓的【幻读】的原因是一样的,但是【幻读】并没有很常见的应用场景。

解决的方法,也是与【幻读】的解决方法一样的,所有的教程都这么说:只有 serializable 隔离级别可以阻止幻读。

下次再说 serializable,串行化的事务。

广州必简信息科技有限公司 版权所有 粤ICP备15047625号-2