MySql锁与事务

MySql锁与事务

事务的四个特性中，其中原子性由undo log实现，持久性由redo log实现，那么隔离性就是由锁来实现的。

概述

在编程中，锁是为了协调多个访问者并发的访问同一个资源的机制。为了保证数据的完整性和一致性，一次只能允许一个访问者访问，其他访问者只能等待。当持有锁的访问者释放后，其他访问者才能够获取锁，如果获取到则允许访问。

锁机制为mysql的各个隔离级别提供了保证，但是锁冲突是影响数据库并发访问性能的因素。

理论部分

前面说到跟隔离级别相关的四个问题：脏写、脏读、不可重复读、幻读。这些问题可以通过锁的方式来进行避免。

这里要明确的是，读锁与读锁之间是可以并行的，不存在竞争问题，但是写锁与读锁、写锁与写锁之间会有锁竞争问题，因为写操作会造成数据的改变，为了保证一致性，自然需要进行等待。

对于并发事务引起的脏写问题，可以在对数据行进行修改时加写锁，这样其他事务就不能进行修改只能进行等待，在事务提交时，唤醒其他写等待事务，这样对单行记录的修改就变成了串行，自然就不会出现脏写。

对于并发事务引起的脏读、不可重复读问题，对读取的数据行加读锁，对写的数据加写锁，由于读锁与写锁互斥，当前事务在读取时，其他事务不能进行写操作，只有等当前事务提交，释放锁之后，其他事务才能够进行写操作，对于当前事务自然就不会读取到其他事务还在修改的数据（想修改的事务由于竞争关系都在等待），避免了脏读。既然其他写事务都在等待，无法提交，自然重复读取能够保证数据一致，避免了不可重复读。

对于并发事务引起的幻读问题，无法简单的只对某些数据进行加锁，因为对某些数据进行加锁只能够控制这些数据，对于新数据而言，没有办法做到，常规的加锁还是无法避免幻影记录的出现，所以需要更重量级的锁，如果将表锁住，导致所有的事务都只能串行执行，不出现并发情况，想进行新增，由于表被锁住只能等待，从而避免了幻读。

可见引入锁机制，控制锁的粒度，脏写、脏读、不可重复读、幻读这些问题都不会出现

上述的锁理论很明显可以看出来性能较为低下，因为它使得读写变成了串行操作，从而影响了系统的性能。为了提高系统的吞吐量，还有另外一种方式来解决脏读、不可重复读、幻读的问题（脏写问题只能依赖行级锁），那就是MVCC（即Multi-version concurrency control，多版本并发控制）

所谓MVCC即维护数据的多个版本，每个事务都只能看到它可见范围内的数据。因此出现了两个概念，即快照读和当前读。快照读是指读取当前事务能够看到的数据，有可能是历史版本，当前读是指读取数据的最新版本，为了确保是最新的，读取时对数据进行加锁（参考前面的锁理论）

MVCC在快照读的情况下，由于读取的是可见范围内的数据（可以简单理解为版本号小于当前事务版本的数据），对于脏读自然不可能出现，因为其他事务并未提交，不会出现在可见范围内。对于不可重复读自然不可能出现，因为即使其他事务提交，版本号也会比当前事务的版本大，属于不可见范围内的数据，对于新增或删除的数据自然版本号也在当前事务之后，所以快照读不会出现脏读、不可重复读、幻读

MVCC的当前读如果没有锁机制那么就约等于裸奔，所以对于当前读想要避免脏读、不可重复读、幻读这些问题需要引入锁来进行保证（与上述锁理论中描述的相同）

那么在快照读转换为当前读时很可能出现不可重复读、幻读（由于当前读引入了锁，所以不会出现脏读），因为快照和最新数据有可能不一致

如果有当前读的业务需求，又不能忍受出现不可重复读、幻读的情况，一定要在一开始就进行一次当前读，锁定数据，这样数据就不会被其他事务影响，虽然这样性能会比较差。

mysql中实现

1. 读未提交：仅仅只是通过行级锁避免了脏写问题，脏读、不可重复读、幻读都会出现
2. 读已提交：使用MVCC机制的快照读，每次进行读取时都重新生成快照，这样就不会读取到其他事务未提交的版本从而避免了脏读，其他事务提交的版本，重新查询时会体现
3. 可重复读：使用完整的MVCC实现，对于快照读，第一次普通查询时生成快照，后续都是用它，这样就解决了不可重复读和幻读的问题，对于当前读，使用了锁保证了不可重复读和幻读不会出现。但是如果事务中有快照读转换为当前读的情况还是会出现不可重复读和幻读的情况（原因就是重新生成了快照，快照内容可能发生了变化）。
4. 可串行化：事务串行，没什么好说的