浅谈 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://blog.csdn.net/closurer/article/details/54291241 相似，【检查用户是否存在】、【添加新用户】两个操作写在同一个事务中，第一个操作放置更新锁。

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

执行完毕后，第一个连接结果如下：

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

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

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

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

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

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

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