数据库第一类第二类丢失更新

数据库在多任务并发的时候会发生两类数据丢失的问题，第一类数据丢失的问题是关于回滚覆盖的，第二类数据丢失的问题是更新覆盖。目前主流数据库支持的所有的隔离级别基本杜绝了第一类数据更新丢失的问题，但是第二类数据更新丢失的问题任然需要用户在使用数据库的时候注意。

数据库第一类更新丢失的问题

第一类更新丢失是指，由于某个事务的回滚操作，参与回滚的旧数据将其他事务的数据更新覆盖了。比如如下两个事务，事务一先开启查询账户有1000元，然后准备存款100元，使其账户变为1100，此时事务尚未结束，其后，事务二发生了转账，并提交了事务，使账户金额变为900，而事务一并不知情，最后事务一没有提交，而是回滚了事务，将账户金额重新设置为1000。但其实，账户已经被转走了100元，这种回滚导致了更新丢失。

SQL92没有定义这种现象，标准定义的所有隔离界别都不允许第一类丢失更新发生。基本上数据库的使用者不需要关心此类问题。

时间序号	事务一	事务二
T1	开启事务	开启事务
T2	查询账户money=1000	查询账户money=1000
T3	存款100，money=1100
T4
T5		转账100，money=900
T6		提交事务，money=900
T7	取消事务，回滚，money=1000

数据库第二类更新丢失的问题

第二类数据丢失的问题是关于多个事务同时更新一行数据导致的问题，如下表所示，事务一和事务二都更新一行数据，他们事务开始的时候都查询到账户有1000元，然后都往账户添加了100元，最后大家都提交了各自的事务，结果却是错误的。

时间序号	事务一	事务二
T1	开启事务	开启事务
T2	查询账户money=1000	查询账户money=1000
T3	存款100，money=1100
T4
T5		存款100，money=1100
T6		提交事务，money=1100
T7	提交事务，money=1100

第二类更新丢失的问题，如果数据库用户使用方式不对，是有可能出现问题的。
通常有两种方式可以解决这个问题：

#悲观锁
#悲观锁就是锁定要更新的这一行，然后在事务提交之前不让其他事务对该行数据做任何操作
#直至释放行锁
select money from account where id=10 for update
money = money + 100
update account set money =  money where id =10

#乐观锁
#乐观锁是在并发的表上加一个version字段，更新的时候只有版本号大于当前版本号才能更新成功
select money，version from account where id=10 for update
money = money + 100
version = version + 1
update account set money =  money where id =10 and version > version