MySQL innoDB的事务隔离

关于事务的特性？

ACID 原子性，一致性 ，隔离性 ，持久性。

innoDB 中的事务的隔离级别？

1. 读提交： 一个事物在已提交的时候才可以被其他事务看到
2. 可重复读： 一个事务在执行过程中看到的数据，总是跟另个一个事物在启动时看到的数据是一致的，只要事务未提交都对其他事务是不可见的。
3. 读未提交：这个事务还未提交就可以被其他事物所看到的。
4. 串行化：读 会加“读锁” 写会加“写锁” 当事务发生冲突的时候有锁的存在则会等着这个事务执行完才会执行下一个。

疑问： 那读提交和可重复读有什么区别吗？ 是的，我也有这个疑问，读提交和可重复读不都是在提交后对其他事务可见。确实是这样 但是读提交在另一个事务提交后再去读取的值时则会读取到已提交事务更改的值。而可重复读是不会的。就算提交了这个事务读取也是初始读取到的值。

事务的隔离的实现

事物的隔离性是如何实现的呢？ 当一个事物进行的时候，每一次更改操作都会有一个回滚记录，[比如下图]

graph LR
1update为2-->2update为3
2update为3-->3update为4
3update为4-->当前值4

其中不包括当前值都为回滚段，分别为3个事务，列如可重复读取当为1的时候，然后可重复读取的隔离性会将1读取到 就算1已经update为2 并且comit了。也会拿到出示的数据，如果说这个跟事物时间太长 然后 又来一个事务这个事物的隔离性是其他类型的，比如可重复读的就会继续更改这个值 连续执行了好几个事务 改了好几次，但是刚开始执行的事务未提交，所以说他这个回滚视图是不能被删除的（删除条件：当系统里面没有整个回滚日志更早的read——view的时候，这个回滚日志就会被删除）做一就会堆积日志，占用大量的内存。（其实我自己也感觉自己写的这个很难理解很不清楚，所以↓）

参考下面的（来自极客专栏）：

~~（在可重复读的隔离级别下，如何理解**当系统里没有比这个回滚日志更早的 read-view 的时候**，这个回滚日志就会被删除？

这也是**尽量不要使用长事务**的主要原因。

比如，在某个时刻（今天上午9:00）开启了一个事务A（对于可重复读隔离级别，此时一个视图read-view A也创建了），这是一个很长的事务……

事务A在今天上午9:20的时候，查询了一个记录R1的一个字段f1的值为1……

今天上午9:25的时候，一个事务B（随之而来的read-view B）也被开启了，它更新了R1.f1的值为2（同时也创建了一个由2到1的回滚日志），这是一个短事务，事务随后就被commit了。

今天上午9:30的时候，一个事务C（随之而来的read-view C）也被开启了，它更新了R1.f1的值为3（同时也创建了一个由3到2的回滚日志），这是一个短事务，事务随后就被commit了。

……

到了下午3:00了，长事务A还没有commit，为了保证事务在执行期间看到的数据在前后必须是一致的，那些老的事务视图、回滚日志就必须存在了，这就占用了大量的存储空间~~。）~~~~