MySQL系列-事务及乐观锁悲观锁

以下我们针对innoDB存储引擎进行分析，作为MySQL的默认存储引擎，innoDB越来越重要了。

1.什么是事务

数据库事务（Database Transaction）,是指作为单个逻辑工作单元执行的一系列操作，要么完全执行，要么完全地不执行。

比如说简单的转账事务包含两个SQL语句，一条是给转账人减钱，另一条是给被转账人加钱，这俩条SQL要么都执行，要么读不执行，不允许中间因为停电或者出现异常而只执行一条。出现这种情况会自动回滚 即都不执行。

2.事务的特性

一般来说，事务是必须满足4个条件（ACID）：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）

原子性（A）：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。

一致性（C）：一致性是指事务必须使数据库从一个一致的状态变到另外一个一致的状态，也就是执行事务之前和之后的状态都必须处于一致的状态。

隔离性（I）：隔离性是指当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离

持久性（D）：持久性是指一个事务一旦被提交了，那么对于数据库中的数据改变就是永久性的，即便是在数据库系统遭遇到故障的情况下也不会丢失提交事务的操作。

3.在MySQL中使用事务

在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作，相当于一条SQL就是一个事务。因此要显式地开启一个事务务须使用命令 begin 或 start transaction，或者执行命令 set autocommit=0，用来禁止使用当前会话的自动提交。rollback命令会使事务回滚，使在事务中执行的SQL的无效。

4.事务的隔离级别

Read Uncommitted（读取未提交内容，简称RU）

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容，简称RC）

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别会产生不可重复读（Nonrepeatable Read）的问题，因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重复读，简称RR）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，但是有个新问题，幻读 (Phantom Read)，就是会读取到别的事务新插入的数据，也称之为幻影数据。不可重复读着重的是读取到别的事务修改的数据，而幻读着重的是读取到别的事务插入的数据。

Serializable（可串行化） 

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之就是读加读锁写加写锁。在这个级别，可能导致大量的超时现象和锁竞争，并发粒度最低。

MySQL在RR级别下就解决了幻读问题，因为innoDB实现了MVCC，在快照读的情况下解决了幻读问题，对于当前读来说，读完之后就直接加锁 ，其他事务也无法插入数据，必须等待上一个事务释放锁，既然都无法插入数据那么两次当前读读取的数据也就不存在幻影数据了，具体的就涉及到GAP锁（间隙锁）了，后面有博客会详细说明。

select @@global.tx_isolation,@@tx_isolation; 查看默认的事务隔离级别和当前会话的事务的隔离级别。

set global transaction isolation level read committed; //设置默认事务隔离级别

set session transaction isolation level read committed; //设置当前会话的事务的隔离级别

事务是如何加锁的：这就是2PL (二阶段锁)，Two-Phase Locking。2PL就是将加锁/解锁分为两个完全不相交的阶段。加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁。

5.乐观锁和悲观锁

乐观锁的悲观锁是一种机制不是指具体的锁。

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。Java synchronized 就属于悲观锁的一种实现，每次线程要修改数据时都先获得锁，保证同一时刻只有一个线程能操作数据，其他线程则会被block。

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，乐观锁适用于读多写少的应用场景，这样可以提高并发粒度。

悲观锁实现：事务隔离级别的可串行化就是典型的悲观锁机制，读加读锁，写加写锁。这是基于锁的并发控制。

乐观锁实现：innoDB引擎的乐观锁机制是通过MVCC实现的。MVCC即Multi-Version Concurrency Control，中文翻译过来叫多版本并发控制（读不加锁读写不冲突）。顾名思义MVCC是通过保存数据在某一个时间点的快照来实现的。因此每一个事务无论执行多长时间看到的数据，都是一样的。

增删改操作都属于当前读，不会读取历史版本的快照数据。

普通的select属于快照读，读取的是快照数据也可能是历史数据。手动加锁的select是当前读 例如：select * from tb for update或者select * from tb lock in share mode

6.实测：innoDB的MVCC在各种隔离级别下的表现

Read Uncommitted就不进行测试了，读取未提交的数据。

下面测试Read Committed级别（RC级别不会读取快照数据，因为只需要保证读提交即可）

先准备数据：

把会话设置为RC级别

开启一个新会话，在一个未提交的事务中修改数据

在原先的会话中查询

无法查询到数据，除非新会话把事务提交。

 

下面测试Repeatable Read级别：

同样准备数据

开启两个会话，会话1和会话2。

首先会话1中开启事务进行数据查询

然后会话2修改数据id为1的把name改为aaa并且提交事务。

然后在会话1中进行查询

发现查询到的是历史数据，如果使用当前读呢？

使用当前读查询到的是最新的数据。

如果我们在当前事务中修改数据会使得快照数据更新

其实只是更新了自己修改的那一部分，其他事务修改的仍然无法见。

但是使用当前读一定可以获取。

使用当前读获取了最新的数据。

因为读取的是快照数据，所以也不会有幻读问题，在会话2中插入数据并提交。

在会话1中进行查询

可以看到，除非是当前读，否则就是读取历史数据。如果把隔离级别调整为RC反而能看到最新数据。

 

Serializable级别就是干什么都加锁，解决了大量的问题，同时也极大的限制了并发粒度。

读取数据就加了读锁，其他事务只能加读锁，加写锁会被阻塞。

基于MVCC的隔离级别则读取数据不会加锁。

把同样的代码改成RR级别在实验一次：

可以看到，会话1并没有进行加锁。