事务丢失更新问题及乐观锁、悲观锁机制

学习计划的第四天，仍然是对数据库事务方面进行学习。毕竟数据库操作在后端开发中有着举足轻重的作用。 那么，今天的学习内容是：事务丢失更新问题及乐观锁、悲观锁机制。 话不多说，进入正题。 什么是事务的丢失更新问题？ 两个或多个事务更新同一行，但这些事务彼此之间都不知道其它事务进行的修改，因此第二个更改覆盖了第一个修改 。 这样说太抽象，举个例子：在数据库表中存在一条数据

id：100
name：张散
age：20

此时，两个管理员同时查询到了这条数据，此时，A管理员发现该数据的名字出错了，于是更新数据，将该数据改为

id：100
name：张三
age：20

然后A管理员提交了更新操作。这个时候，B管理员也发现该数据的年龄出错了，于是准备进行更改，但是B管理员根本就不知道A管理员进行了姓名的更改，于是B管理员进行了如下修改

id：100
name：张散
age：21

然后B管理员提交了更新操作。操作完成后，数据库表的数据变为了

id：100
name：张散
age：21

这时候问题就出现了，A管理员发现姓名出错进行了修改，而B管理员却把正确的名字给改了回去，B管理员的修改就覆盖了A管理员的修改，这种现象就是丢失更新。 贴张图方便大家理解。

在这里插入图片描述

那么该如何解决丢失更新问题呢？(丢失更新问题的解决)

• 悲观锁(Pessimistic Locking)
• 乐观锁(Optimistic Locking)

现在来依次解读两个方法解决丢失更新问题。 悲观锁原理：使用数据库内部锁机制，进行数据库表的锁定。就是在A管理员修改数据时，A管理员就将数据锁定，此时B管理员无法进行修改、查询。避免两个事务同时修改，也就解决了丢失更新问题。 很多人觉得这个名字很奇怪，为什么要叫悲观锁，可以顺带解释一下，因为我们假设丢失更新会发生，是一个悲观的态度。

还是举个例子实现一下： 在MySQL中，默认情况下，当你修改数据，会自动地为数据加锁，以防止两个事务同时修改数据，但是有个前提，就是必须在事务中才会自动加锁，事务和锁是不可分开的，锁一定是在事务中才能使用，当事务关闭锁自动释放。 开启两个MySQL窗口，并查询表数据

在这里插入图片描述

然后在两个窗口均开启一个事务，接下来在左边窗口输入

update account set money = money - 100 where name = 'ccc';

但是不要提交，然后两边分别查询数据

在这里插入图片描述

这个情况肯定是可以理解的，因为左边窗口未提交，所以右边窗口数据未改变。此时，在B窗口输入

update account set money = money - 100 where name = 'ccc';

会发现，当你执行该条语句后，数据库被阻塞了，因为数据被加上了锁，不允许两个事务同时修改。但是在左边窗口是可以进行数据修改的，右边窗口才会进入阻塞状态。 需要注意的是，虽然右边窗口无法进行修改，但是是可以进行查询的，所以这把锁是读锁。 由此，我们来了解一下MySQL的锁类型。 在MySQL内部有两种常用的锁，一种叫读锁，又叫共享锁；另一种叫写锁，也叫排它锁。一张表可以添加多个读锁，如果某张表添加了读锁，但又不是当前事务添加的，该表就不允许修改。添加读锁的sql语句为

select * from table lock in share mode;

演示一下。 在左边窗口开启一个事务，然后输入

select * from account lock in share mode;

此时该表就被加上了读锁，只允许加锁的事务修改。 现在，在两个窗口分别重新开启一个事务，然后分别输入

 select * from account lock in share mode;

此时，该表就被加上了两把读锁，这时候两个窗口都将不能修改表数据。如果在两个窗口分别执行更新语句，将会因为两个窗口都在互相等待对方释放锁从而发生死锁问题。 强调一下，读锁是非常容易发生死锁问题的。 接下来要分析的便是写锁了。

要注意，一张表只能加一个排它锁，排它锁和其它的共享锁都具有互斥效果。通俗一点说就是，一张表如果想加排它锁，在它之前，就不能加别的共享锁和排它锁。添加写锁的sql语句为

select * from table for update;

当一张表在一个事务中加上了写锁后，别的事务将不能够修改该表数据，因为修改数据会自动加上读锁，进而产生互斥。 那既然有两种方法可以解决丢失更新问题，那到底选择哪种方法是关键。 其实解决丢失更新问题是不能用读锁去解决的，而应该使用写锁解决，原因前面也说了，读锁的弊端是显而易见的。

我们可以使用写锁实现悲观锁来解决丢失更新问题。在原来的案例上加上写锁，B管理员在查询时会因为A管理员在修改数据而等待，直到A管理员提交了事务之后，锁被释放，此时B管理员允许查询，查询到的是A管理员修改后的数据，从而避免了丢失更新问题。

乐观锁原理：使用的不是数据库的锁机制，而是一个特殊标记字段，通过控制字段状态和内容得知数据是否发生了并发访问，正如其名，我们假设丢失更新不会发生，是一个乐观的态度，所以名为乐观锁。那特殊标记字段是什么呢？在实际开发中，一般用到该字段timestamp，(时间戳字段)。 演示一下。 创建一张表，并初始化数据

create table blog(
	id int primary key,
	title varchar(40),
	updatetime timestamp
);

insert into blog values(1,'java学习',null);

创建成功后，查询表数据

‘’

会发现，timestamp字段在插入时自动生成当前时间。 当你修改数据后再次查询，会发现timestamp字段会自动更新为当前时间。 根据该原理，上面的案例中，可以在数据表中新增一个timestamp类型的updatetime字段，然后A、B管理员分别查询数据，然后编写程序，比较用户提交的updatetime与数据表中的updatetime是否一致，如果一致，证明在你修改数据的过程中其他人没有修改过。而当A管理员提交修改后，updatetime字段会自动更新为当前时间，再当B管理员修改数据并提交时，程序比较updatetime字段，发现两者并不一样，证明数据已经被修改了，此时应该通知B管理员重新修改。