浅析MySQL的事务隔离

基本概念

提到事务，我们首先就会想到事务的4个特性（ACID）：原子性，一致性，隔离性，持久性。本篇主要针对隔离性进行一些分析（针对MySQL的InnoDB引擎）。

在数据库中，多个事务同时执行时，不可避免的会相互产生一些干扰：
如：

表T(id PK,name)
已存在数据:
1,zhangsan
2,lisi
3,wangwu

1、脏读
事务A执行insert into T values(4,'zhaoliu')，未commit
事务B执行select * from T，未commit
此时，如果B能够读到A新增的数据，那么事务A就对事务B产生了影响，因为B读到了A事务未提交的数据，这就叫脏读。

2、不可重复度
事务A执行selet * from T where id=1，未commit，结果为1,zhangsan
事务B执行update T set name='abcdef' where id=1，然后commit
事务A再次执行selet * from T where id=1，此时结果为1,abcdef
此时，事务B对事务A产生了影响，A事务内相同的sql语句，得到了不同的结果，这就是不可重复读。

3、幻读
事务A执行select * from T where id>3，未commit，结果为null
事务B执行insert into T values(4,'zhaoliu')，然后commit
事务A根据其之前的查询结果执行insert into T values(4,'zhaoliu')，结果为错误，提示主键已存在
此时，事务B对事务A产生了影响，这个影响叫幻读。

所以，并发执行的事物之间可能存在脏读，不可重复读，幻读的问题。

为了解决这些问题，就有了事务隔离级别。

事务隔离级别有：读未提交（READ UNCOMMITTED），串行化（SERIALIZABLE），读提交（READ COMMITTED，RC）、可重复读（REPEATABLE READ，RR）。

InnoDB中，使用不同的锁策略来实现不同的隔离级别
1、读未提交：一个事务执行过程中，可以获取其他事务未提交的数据。
这种级别下，select不加锁，因为可以读到其他事务未提交的数据，所以会出现脏读。
这是并发最高，一致性最差的隔离级别。

2、串行化：读加读锁，写加写锁，互不争抢，串行执行（读读不互斥，可并行读取）
这种级别下，如果此时有未提交的事务在修改某行数据，所有的select都要等待修改完成。
这是一致性最好，并发性最差的隔离级别。

在互联网大数据量，高并发的场景下，几乎不会使用以上两种隔离级别。

3、读提交：一个事务执行过程中，只能获取其他事务已经提交的数据。
这种级别下，
普通的select是快照读，不加锁。
加锁的select，update，delete等语句，除了在外键约束检查以及重复键检查时会封锁区间，其他时刻都只使用记录锁。
所以范围读取时，其他事务依旧可以插入数据，所以可能会导致幻读。

4、可重复读（InnoDB默认隔离级别）：一个事务执行前后，其看到的数据，总是和事务启动时看到的一样。
这种级别下，
普通的select使用快照读，这是一种不加锁的一致性读，底层使用MVCC来实现。
加锁的select，update，delete等语句，其锁依赖于它们是否在唯一索引上使用了唯一的查询条件，或者范围查询条件。
在唯一索引上使用唯一查询条件，会使用记录锁，而不会封锁记录之间的间隔，即不会使用间隙锁和临键锁
范围查询条件会使用间隙锁和临键锁，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻读和不可重复读。
普通的读取还是可能会产生幻读的。

关于MVCC（多版本并发控制），记录锁，间隙锁，临键锁，在之后的文章中解释。
只用记住这里的MVCC相当于给数据做了个副本，操作都在事务的数据副本上，所以避免了不可重复读的问题
记录锁相当于单行加锁，间隙锁和临临键锁相当于区间锁（即for update），防止读取时添加记录导致前后读取结果不一样

使用

事务的启动方式有两种：
1、显式启动set autocommit=1，begin或start transaction，提交为commit，回滚为rollback，默认不写则一个sql，commit一下。
2、手动提交，set autocommit=0，这个配置会将线程的自动提交关闭，也就是说执行一条语句，事务就启动了，且不会自动提交，直到手动写commit或rollback或断开连接。

推荐使用set autocommit=1，通过begin启动事务，commit提交使用，commit work and chain 则是提交事务并自动开启下一个事务。

事务是可以回滚的，其回滚是基于回滚日志来操作的，如果基于一行数据，有许多事务长时间一直未commit连接该行数据（可重复读RR下），由于这些事务可能操作任何数据，所以该事务提交前可能用到的所有回滚记录都必须保存，这就会导致回滚日志占用大量的存储空间，且长事务还占用锁资源，可能会拖垮整个库。

因此，我们应尽量避免使用长事务。
如：

• 测试环境开启general_log查看到达MySQL Server的sql，尽量避免set autocommit=0。关于general_log的解析
• 只读事务避免使用beigin/commit。
• 根据业务情况设置set max_execution_time的值来控制每个sql执行的最长时间

可通过以下命令修改事务隔离级别：

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
  {
       REPEATABLE READ
     | READ COMMITTED
     | READ UNCOMMITTED
     | SERIALIZABLE
   }

查看当前使用的隔离级别：

show variables like 'transaction_isolation'
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.08 sec)

我们可以在information_schema库的innodb_trx这个表中查询长事务。
如：查询持续时间超多60秒的事务：
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
根据这个表中的内容，我们可以编写一些长事务报警程序，进行业务监控。

最后

网上看到关于第一类丢失和第二类丢失的内容，贴出来大家讨论：
第一类丢失：A事务在回滚时，造成已完成B事务的汇入金额丢失。（当前所有隔离级别都会避免此种情况）

第二类丢失：A事务覆盖B事务提交的数据，造成B事务所做的操作丢失。（应注意避免）

第一类第二类丢失更新