start transaction；
update from account set money=money-100 where name=‘a‘;
update from account set money=money+100 where name=‘b‘;
commit；

update from account set money=money-100 where name=‘a‘;
update from account set money=money+100 where name=‘b‘;
commit；

        

 锁机制

     排它锁：

start transaction;
 
select * from user where userId = 1 for update;

     共享锁：

 实例讲解

如果我们采用的是第一个方案时，老公进行查询操作，数据库为表增加了共享锁，老婆进行查询操作时数据库也增加了一个共享锁。但是当老公进行更新数据库操作时，由于老婆拿着共享锁，导致老公不能增加排它锁，老婆进行更新操作时，因为老公拿着共享锁，导致老婆也拿不到排它锁，这就发生了死锁现象，你等我，我等你。在 mysql 中，处理死锁的方案是释放掉一方的锁。这样就保证了一方更新成功，但是这种性能极低，因为数据库频繁在解决死锁问题。

悲观锁（更新多，查询少时用）

如果我们采用的是第二个方案时，即采用悲观锁。就是我们在操作数据库时采用悲观的态度，认为别人会在此时并发访问数据库。我们在查询语句中 select * from account where name=‘aaa‘ for update; 等于加了排它锁。当老公查询余额的时候，select money from account where name=‘aaa‘ for update; 增加了排它锁，老婆查询账户余额的时候， select money from account where name=‘aaa‘ for update；也要求对数据库加排它锁，因为老公已经拿到了排它锁，导致老婆不能加锁，所以老婆只有等待老公执行完毕，释放掉锁以后才能继续操作。

乐观锁（更新少，查询多时用）

如果我们采用的是第三个方案时，即采用乐观锁，就是我们在操作数据库的时候会认为没有其它用户并发访问，但是乐观锁也不是完全乐观的，乐观锁是采用版本号的方式进行控制的。在数据库表中有一列版本号。从数据库中查询的时候，将版本号也查询过来，在进行更新操作的时候，将版本号加1，查询条件的版本号还是查询过来的版本号。比如，老公执行查询操作的时候，select money,version from account where name=‘aaa‘; 假设此时查询到的版本号为 0，老公在进行更新操作的时候 update account set money=money+100,version=version+1 where name=‘aaa‘ and version=0; 未提交时老婆来查询，查询到的版本号依然是 0，老婆也执行更新操作 update account set money=money+100,version=version+1 where name=‘aaa‘ and version=0; 现在老公提交了事务，老婆再提交事务的时候发现版本号为 0 的记录没有了，所以就避免了数据丢失的问题。不过这种情况也导致了多个用户更新操作时，只有一个用户的更新被执行。

附：各数据库默认事务级别

1、mysql的默认事务的隔离级别：可重复读取(repeatable read);

2、sqlserver的默认事务的隔离级别：提交读取(read committed);

3、oracle的默认事务的隔离级别：提交读取(read committed).