MySQL-(InnoDB)事务和锁

在事务并行处理背景下，不同的事务之间因数据共享的状态变化，存在着某种依赖/隔离影响。即事务隔离级别。

事务隔离级别，官网的解释在这里。

InnoDB提供 SQL:1992 标准描述的所有四种事务隔离级别： READ UNCOMMITTED、 READ COMMITTED、 REPEATABLE READ和 SERIALIZABLE。
InnoDB默认的隔离级别是 REPEATABLE READ。

READ UNCOMMITTED（未提交读）：即一个事务可以读到另一个事务未提交的“中间状态”数据。也叫脏读。好比A和B在画画，A想看看B的绘画结果，

但是B还没画完，A就拍照走了。实际B的画没有完成；A只是拿了一个中间状态。

READ COMMITTED（提交读）：即一个事务不可读到另一个事务未提交的“中间状态”数据。可以避免脏读。但是会发生两次读到的数据不一致问题。

也叫不可重复读。还是A和B画画举例，A在B画画之前读一次，B画完后读一次。A读了两次读到了不同的内容（想当然）。

REPEATABLE READ（可重复读）：对不可重复读的改进（可以看到改进在一条条升级）。即两次读到的内容一致。举例来说，即A开始读B的画，

B即交笔停笔不允许改了。不管A读几次结果都一样。直到A结束他的读（事务）。

可重复读仍会产生幻读问题。

幻读这里有点绕，和不可重复读有点像。都是两次读到了不同的结果。不同的是：不可重复读强调查询结果的值的改变，幻读强调查询结果的范围出现了变化，

比如某行数据上一次查询没有，这一次突然出现--这是幻读问题。

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

SERIALIZABLE（可串行化）：强制事务进行排序，将并行事务改串行，可以解决脏读，不可重复读，幻读的问题，但是需要加锁。不是很友好。

上面介绍了四种事务隔离级别和各隔离级别仍存在的问题，需要注意的是：READ UNCOMMITTED这种最低一级的隔离级别，相当于没有隔离，

实际应用中基本上不会用。SERIALIZABLE隔离级别会对每一行数据进行读写加锁，可能导致大量的超时和锁争用问题，实际应用中也很少用这个

隔离级别，除非接受没有并发，但我们也知道，基本不可能。

所以我们更多的讨论的是READ COMMITTED和REPEATABLE READ这两个事务隔离级别。

即在READ COMMITTED和REPEATABLE READ这两个事务隔离级别下，如何解决不可重复读和幻读的问题？

通过锁机制和MVCC。其中锁主要处理当前读相关问题，MVCC处理快照读相关问题。

mysql锁的分类 InnoDB Locking

根据锁的覆盖范围，重点关注：表锁，行锁，间隙锁，临键（next-key）锁

MVCC部分待续。

附录总结一

**mysql事务(ACID)的实现原理：

原子性（Atomicity）： undo log

一致性（Consistency）：一致性是目的，原子性、隔离性、持久性是手段。实现AID三大特性才有可能实现一致性。

隔离性（Isolation）： 写写：锁（行锁，表锁，间隙锁）；写读：MVCC

持久性（Durability）：redo log