MYSQL事务隔离个人笔记-极客时间MYSQL四十五讲

Mysql事务隔离笔记

事务隔离实例分析

Q: 事务B执行过程中，事务A查询得到的V1，V2和V3的返回值分别是多少?

 	1. 具体什么值要根据事务隔离级别来分析;
 	2. 事务隔离级别分为:读未提交，读提交，可重复读，串行化；
 	3. 如果是读未提交级别，不管是事务A还是事务B，都是**当前读**，那么事务A读到的V1，V2和V3的值都是2;
 	4. 如果是读提交级别(事务B提交之后，事务A才能读到B做的修改)，那么事务A读到的V1值是1，读到的是V2是2，因为事务B已提交，V3也是2；
 	5. 可重复读，指的是事务执行期间看到的数据前后必须是一致的，所以v1是1，v2是1，v3是2;
 	6. 串行化，则在事务 B 执行“将1改成2的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从 A 的角度看， V1、V2 值是 1，V3 的值是 2。 

隔离级别是怎么实现的

1. 读未提交级别，读的都是最新的数据，这时候没有一致性视图概念;
2. 读提交级别，每个SQL语句开始执行的时候会创建一个一致性视图快照，所以，在上述实例分析中，事务A在事务B提交之后，执行查询时创建的视图快照读到的V2就是2;
3. 可重复读级别，是在事务开始的时候就创建了一个一致性视图快照，所以事务A在事务期间一直读的数据都是以事务Aid为准的版本快照数据;
4. 串行化级别，事务一个个执行，事务A执行完，才轮到事务B，不存在视图概念;

笔记要点

1. 事务的特性：原子性、一致性、隔离性、持久性
2. 多事务同时执行的时候，可能会出现的问题：脏读、不可重复读、幻读
3. 事务隔离级别：读未提交、读提交、可重复读、串行化
4. 不同事务隔离级别的区别：
   读未提交：一个事务还未提交，它所做的变更就可以被别的事务看到
   读提交：一个事务提交之后，它所做的变更才可以被别的事务看到
   可重复读：一个事务执行过程中看到的数据是一致的。未提交的更改对其他事务是不可见的
   串行化：对应一个记录会加读写锁，出现冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行
5. 配置方法：启动参数transaction-isolation
6. 事务隔离的实现：每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。
7. 回滚日志什么时候删除？系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。
8. 什么时候不需要了？当系统里么有比这个回滚日志更早的read-view的时候。
9. 为什么尽量不要使用长事务。长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。
10. 事务启动方式：一、显式启动事务语句，begin或者start transaction,提交commit，回滚rollback；二、set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个select语句，事务就启动，并不会自动提交，直到主动执行commit或rollback或断开连接。
11. 建议使用方法一，如果考虑多一次交互问题，可以使用commit work and chain语法。在autocommit=1的情况下用begin显式启动事务，如果执行commit则提交事务。如果执行commit work and chain则提交事务并自动启动下一个事务。

为什么不要长事务

1. 在可重复读的隔离级别下，如何理解当系统里没有比这个回滚日志更早的 read-view 的时候，这个回滚日志就会被删除？这也是尽量不要使用长事务的主要原因。

2. 具体例子:

   1. 比如，在某个时刻（今天上午9:00）开启了一个事务A（对于可重复读隔离级别，此时一个视图read-view A也创建了），这是一个很长的事务……
   2. 事务A在今天上午9:20的时候，查询了一个记录R1的一个字段f1的值为1……
   3. 今天上午9:25的时候，一个事务B（随之而来的read-view B）也被开启了，它更新了R1.f1的值为2（同时也创建了一个由2到1的回滚日志），这是一个短事务，事务随后就被commit了。
   4. 今天上午9:30的时候，一个事务C（随之而来的read-view C）也被开启了，它更新了R1.f1的值为3（同时也创建了一个由3到2的回滚日志），这是一个短事务，事务随后就被commit了。
   5. 到了下午3:00了，长事务A还没有commit，为了保证事务在执行期间看到的数据在前后必须是一致的，那些老的事务视图、回滚日志就必须存在了，这就占用了大量的存储空间。
   6. 源于此，我们应该尽量不要使用长事务。