MySQL事务

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

第一类丢失更新(回滚丢失，Lost update)

A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来：

 

A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。

SQL92没有定义这种现象，标准定义的所有隔离界别都不允许第一类丢失更新发生。

第二类丢失更新(覆盖丢失/两次更新问题，Second lost update)

A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：

 

上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。

第二类丢失更新，实际上和不可重复读是同一种问题。

有些系统中第二类丢失更新可能就影响很大了，举个简单的例子： 财务系统加工资，若公司本次调薪决定给员工张三加1k人民币，财务部两名操作人员A和B，过程情况若是这样的： 1）A操作员在应用系统的页面上查询出张三的薪水信息，然后选择薪水记录进行修改，打开修改页面但A突然有事离开了，页面放在那没有做任何的提交。 2）这时候B操作员同样在应用中查询出张三的薪水信息，然后选择薪水记录进行修改，录入增加薪水额1000，然后提交了。 3）这时候A操作员回来了，在自己之前打开的薪水修改页面上也录入了增加薪水额1000，然后提交了。 其实上面例子操作员A和B只要一前一后做提交，悲剧就出来了。后台修改薪水的sql：update 工资表 set salary = salary + 增加薪水额 where staff_id = ‘员工ID’。这个过程走下来后结果是：张三开心了这次涨了2k，操作员A和B都郁闷了。

解决思路： 基本两种思路，一种是悲观锁，另外一种是乐观锁； 简单的说就是一种假定这样的问题是高概率的，最