简单了解MySQL锁、事务和MVCC--事务并发可能导致的问题

通过上个问题我知道单条 DDL 执行也会被当成一个事务自动提交，那么无论是多条SQL并发，还是多个自己手动组织的包含多条SQL的事务并发，都会导致事务并发问题。

具体来说有：

• 脏写 （一个事务提交的数据覆盖了另一个事务未提交的数据）
• 脏读 （一个事务读取到另一个事务未提交的数据）
• 不可重复读 （重点在于update和delete 一个事务内多次读取的数据不一样）
• 幻读 （重点在于insert 一个事务内多次读取的记录数不一样）

上面我们提到了事务的隔离级别，MySQL 的所有隔离级别都能保证不产生脏写，所以就剩下脏读、不可重复读和幻读的问题了。

下面具体看下各隔离级别是如何解决或未解决上面这些问题的：

Read uncommitted

未提交读，这个级别在读的过程中不会加任何锁，只在写请求时加锁，所以写操作在读的过程中修改数据，就会造成脏读。也自然会产生不可重复读和幻读。

Read committed

已提交读，与未提交读一样也是读不加锁，写加锁。不一样的是利用了 MVCC 机制避免了脏读的问题，同样会有不可重复读和幻读的问题。关于 MVCC 我们后面会详细说。

Repeatable read

MySQL 默认的隔离级别，在这个级别 MySQL利用两种方式解决问题

1. 读写锁 读读并行时加读锁，读读是共享锁的。 只要有写请求就加写锁，这样读写是串行的。 读取数据时加锁，其它事务无法修改这些数据。所以不会产生不可重复读。 修改删除数据时也要加锁，其它事务无法读取这些数据，所以不会产生脏读。 第一种方式就是我们常说的 “悲观锁”，数据在整个事务处理过程中处于锁定状态，比较保守，性能开销比较大。
2. MVCC （后面讲）

此外还利用了Next-Key锁 在一定程度上解决了幻读的问题。关于这个我们后面再说。

Serializable

在该隔离级别下事务都是串行顺序执行的。 如果禁用了自动提交，则 InnoDB 会将所有普通的 SELECT 语句隐式转换为 SELECT ... LOCK IN SHARE MODE。即给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。