Mysql之事务隔离

隔离级别

SQL 标准的事务隔离级别包括：

• 读未提交（read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到
• 读提交（read committed）：一个事务提交之后，它做的变更才会被其他事务看到
• 可重复读（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
• 串行化（serializable）：顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

隔离级别	脏读	不可重复读	幻影读
READ-UNCOMMITTED	√	√	√
READ-COMMITTED	×	√	√
REPEATABLE-READ	×	×	√
SERIALIZABLE	×	×	×

不同的隔离级别下，事务 A 会有哪些不同的返回结果，也就是图里面 V1、V2、V3 的返回值分别是什么。

• 若隔离级别是“读未提交”， 则 V1 的值就是 2。这时候事务 B 虽然还没有提交，但是结果已经被 A 看到了。因此，V2、V3 也都是 2。
• 若隔离级别是“读提交”，则 V1 是 1，V2 的值是 2。事务 B 的更新在提交后才能被 A 看到。所以， V3 的值也是 2。
• 若隔离级别是“可重复读”，则 V1、V2 是 1，V3 是 2。之所以 V2 还是 1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
• 若隔离级别是“串行化”，则在事务 B 执行“将 1 改成 2”的时候，会被锁住。直到事务 A 提交后，事务 B 才可以继续执行。所以从 A 的角度看， V1、V2 值是 1，V3 的值是 2。

MySQL默认是快照读，是不存在幻读的，幻读只有在“当前读”下才会出现。在可重复读的隔离级别下，MySQL通过next-key lock解决“当前读”下幻读问题。

查看Mysql数据库当前事务隔离级别，默认：REPEATABLE-READ

show variables like '%isolation%';

MySQL为什么默认使用REPEATABLE-READ

session A(READ-COMMITTED)	session B(READ-COMMITTED)
begin;	begin;
delete from t where a=2;
	insert into t values(2,2);
	commit;
commit;

MySQL采用WAL预写式日志，提交事务前先后写redo log、binlog，且采用两阶段提交。先预写redo log，再写binlog，最后提交redo log，而binlog只要写成功既可用于从库同步。

根据MySQL日志写入机制可以看出session B提交后binlog一定写成功了，而session A中binlog在commit前什么时刻写成功不确定。如果是在session B提交后写成功，那么session A中binlog一定在session B之后写入。MySQL 5.0之前，binlog只支持statement格式，即sql语句，从库同步得到的binlog中语句如下：

insert into t values(2,2);

delete from t where a=2;

从库中sql回放顺序和主库完全相反，主从数据不一致。

READ-COMMITTED由于提供了next-key lock，session A执行删除操作时进行了加锁操作，堵塞了session B的插入操作，保证了binlog的写入顺序。因此，MySQL默认将隔离级别设置为可重复读，保证主从复制不出现问题。所以，MySQL 5.0之后，我们也可以采用binlog的row格式+读已提交的隔离级别。

启动方式

MySQL 的事务启动方式有以下几种：

• 显式启动事务语句， begin 或 start transaction，配套的提交语句是 commit，回滚语句是 rollback
• set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句，或者断开连接

查看Mysql数据库当前事务启动方式，默认：ON，即autocommit=1

show variables like '%autocommit%';

建议使用 set autocommit=1，通过显式语句的方式来启动事务，避免长事务

begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令

长事务检测

可以在 information_schema 库的 innodb_trx 表中查询长事务，比如下面这个语句，用于查找持续时间超过 60s 的事务

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

如何避免？

• 确认是否使用了 set autocommit=0？可通过测试环境临时开启general_log查看，或者检测框架参数设置
• 去除只读事务
• 业务连接数据库的时候，根据业务本身的预估，通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间
• 数据库端监控
  • 监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill
  • Percona 的 pt-kill 这个工具不错，推荐使用
  • 在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题
  • 如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。