MySQL数据库锁、MVCC与事务隔离级别的关系
上一篇文章中讲了MySQL的事务隔离级别（mysql数据库事务的隔离级别），有个问题一直困扰了自己很长时间，MySQL的默认事务隔离级别（REPEATBLE-READ）个人理解通过MVCC就可以很好的实现，那MySQL的锁在RR隔离中起了什么作用？这段时间一直在翻查《高性能MySQL》和《MySQL技术内幕：Innodb存储引擎》两本书，有了一个基本的结论，写下来跟大家分享下，理解不到位的地方还请大家指正。
本文默认大家都掌握了MySQL的锁和MVCC机制。MySQL数据库支持两种读操作，一种是快照读，另一种是当前读；所有的快照读都依赖MVCC机制，读取特定的历史版本数据；而当前读就是读取当前最新的数据；个人认为MySQL的RR事务隔离级别中读操作的隔离都是指的“当前读”，而非“快照读”；快照读的确很好的解决了脏读、可重复读、幻读的问题，还没增加锁开销，可谓是兵不血刃，皆大欢喜；因为快照不会被修改，本来就有很好的隔离性，其实不然，快照读读取的数据不是数据库最新的数据，这对一些数据实时性要求较高的应用来说，肯定是有问题的；举个例子：张三账户余额有10000元，balance=10000；要转账给李四9000元，转给王五5000元；这两次转账肯定有一次因余额不足转账失败；
SessionA:
begin;
selectbalancefromaccountwherename='张三';（快照读）
ifbalance>9000{updateaccountsetbalance=balance-9000wherename='张三';updateaccountsetbalance=balance+9000wherename='李四';commit;
}else{余额不足；rollback;
}
SessionB:
begin;
selectbalancefromaccountwherename='张三';（快照读）
ifbalance>5000{updateaccountsetbalance=balance-5000wherename='张三';updateaccountsetbalance=balance+5000wherename='王五';commit;
}else{余额不足；rollback;
}
假设A、B两个事务并发执行，按照MySQL的快照读机制，A、B读取的balance都是10000，并且事务都能正常提交，结果却不符合预期；张三账号有-4000元（透支）。
显然快照读在该应用场景下是有问题的，正确的转账应该是：
SessionA:
begin;
selectbalancefromaccountwherename='张三'forupdate;（当前读）
ifbalance>9000{updateaccountsetbalance=balance-9000wherename='张三';updateaccountsetbalance=balance+9000wherename='李四';commit;
}else{余额不足；rollback;
}
SessionB:
begin;
selectbalancefromaccountwherename='张三'forupdate;（当前读）
ifbalance>5000{updateaccountsetbalance=balance-5000wherename='张三';updateaccountsetbalance=balance+5000wherename='王五';commit;
}else{余额不足；rollback;
}
即使两个事务同时执行，有一个会block在当前读操作上，直到另一个事务提交释放锁，被阻塞事务才能继续执行，并且能够读到最新的数据；
当然MySQL引入快照读对于一些实时性要求不高的操作还是带来很大的性能提升的，因为快照读是不需要加锁的。
既然MySQL的默认事务隔离级别RR是针对“当前读”的，那我们看下是怎么解决当前读的脏读、重复读、幻读的问题；
数据库初始状态：
脏读问题：
事务A：
事务B：
结论：脏读问题通过X锁实现的；
重复读问题和脏读问题基本一样，通过严格的锁控制就能实现；
幻读问题：
事务A：
事务B:
MySQL在解决幻读问题时使用了Gap-Lock，仅仅使用行锁无法解决幻读问题。
结论：
MySQL的事务隔离级别定义都是针对读操作，并且读操作指的是“当前读”；MySQL的默认隔离级别RR使用Gap-Lock来解决幻读，Record-Lock解决脏读和可重复读；因此RR级别是通过Next-Key Lock(Gap-Lock + Record-Lock)实现的；MVCC机制是MySQL为实现一致性非锁定读，提高部分读写效率而引入的机制。
