并发数据库中丢失修改问题的解决措施是本文我们主要要介绍的内容，接下来我们就从一个简单的例子开始介绍这部分内容，希望能够对您有所帮助。
1．问题定义
先从一个较简单的例子为例，如火车售票系统，数据库表（车次，剩余票数），一个售票事务的处理过程如下：
（1） 查询该车次剩余票数x=16。
（2） x = x – 1，得x=15
（3） 将x=15写回该车次剩余票数。
这样一个事务在串行运行的数据库系统中是没有问题的，如果两个事务串行运行，各售一张票，最终结果为14。但如果在并行系统中，可能会有两个售票事务实例同时执行，由于CPU分时间片轮流执行事务，这时有可能发生如下情况（执行次序自上而下，两个事务交叉运行）：
售票事务T1 售票事务T2
（1） 查询剩余票数x=16
（2） 查询剩余票数x=16
（3） x=x-1，得x=15
（4） 将x=15写回数据库。
（5） x=x-1，得x=15
（6） 将x=15写回数据库。
即T1先查询出了剩余票数16，此时它把控制权交给CPU，等待分配下一个时间片执行。然后T2获得了执行权，查出票数依然是16。然后T1和T2不管如何轮换执行，售出一张票后（售多张票是类似的），都将得到结果15。那么后一个事务提交的数据就覆盖了前一个事务的数据，最终结果是15，这就是所谓的丢失修改问题。
这个问题在分布式数据库中具有一般性，其它的例子如申请手机号时，两个用户同时申请同一个手机号的问题，本文中我们给出这类问题的一个通用解决方案。（火车售票例子太简单，还是比较容易解决的，没必要用本文所述的一般性的方法，呵呵）。
2．思路
我们可以采用一个时间戳字段记录哪个事务先修改的记录。时间戳不是一个时间，而类似于一个自动增长字段，但它有一个特点，就是每次更新某条记录时，会自动更新为一个新的时间戳数据。在SQL Server中，设置为一个字段为timestamp数据类型，读取时可以使用varbinary类型读取。
主要思路是：读取剩余票数时就同时读取该记录的时间戳，当更新记录时，判断时间戳是否与原来读取的相同，如果不同，说明已经有一个事务修改了这条记录，就让当前事务失败。
这样我们把数据库表修改为：车次表（车次，剩余票数，修改时间）。注意修改时间字段设置为timestamp类型，不允许为空，这样初始化时就先自动生成了一个时间戳。
3．解决方案
售票的存储过程：
class="dp-xml">
- Create Procedure Sale
- (@Serial varchar(10), -- 车次
- @SaleCount int -- 所售票数
- ) As
- -- 取出剩余票数
- Declare @RealCount int, -- 剩余票数
- @Time varbinary(6) -- 时间戳
- Select @RealCount=剩余票数, @Time=修改时间 From 车次表 Where 车次=@Serial
- -- 判断票数是否够
- If (@SaleCount > @RealCount)
- Begin
- Print ‘票数不够’
- return
- End
- -- 更新数据
- Declare @RowsCount int -- 更新时影响的行数
- Update 车次表 Set 剩余票数=剩余票数-@SaleCount
- Where 车次=@Serial and 修改时间=@Time
- Set @RowsCount=@@RowsCount
- /* @@RowsCount记录了修改最近一条SQL语句影响的行数，如果为1，表示修改成功，如果为0，表示未修改任何行，出现这种情况的原因就是其它事务已经修改了这条记录，造成修改时间这个自动的值变化了 */
- -- 判断结果
- If (@RowsCount = 0)
- Print ‘事务并发造成的修改失败’
- Else
- Print ‘售票成功
- Go
4．测试
测试时我们创建另外一个售票的存储过程SaleDelay，与上面的Sale存储过程不同的是，在取出票数之后增加一个延时语句，比如延时10秒。
Waitfor Delay ‘0:0:10’
先启动SaleDelay，然后快速启动Sale，这样SaleDelay因为读取后10s才去写数据，这期间Sale已经写入了数据，SaleDelay会失败。
测试技巧：在查询分析器中打开两个窗口，最好选用横向平铺让两个窗口都显示出来。两个窗口分别输入exec SaleDelay ‘车次x’ 1和exec Sale '车次x’ 1，注意两个车次号要相同。先点击第一个窗口，然后点执行；然后迅速点第二个窗口，点执行，等待执行结果。
关于并发数据库中丢失修改问题的解决措施的相关知识就介绍到这里了，希望本次的介绍能够对您有所收获！
相关文章
