Mysql
事务的特性
ACID
- A（
Atomicity）：原子性 - C（
Consistency）:一致性 - I（
Isolation）:隔离型 - D（
Durability）:持久性
隔离引发的问题
脏读、幻读、不可重复读、丢弃修改
-
脏读：A事务读取到B事务未提交的数据
脏读.png
-
幻读/虚读：A事务读B事务提交的数据，在B事务提交前后读取到的数量不一致
幻读.png
-
不可重复读：A事务读B事务提交的数据，在B事务提交前后读取到的数据不一致
不可重复读.png
-丢弃修改：A、B事务对一个数据进行修改，A先修改，B后修改，B修改覆盖了A修改的
丢弃修改.png
事务隔离级别
读未提交、读提交、可重复读、串行化
- 读未提交：A事务没有提交，其他事务能读取到A的变更。导致脏读。
- 读提交：A事务没有提交，其他事务不能读A的变更，只有A提交事务后才能被读取。解决了脏读，会导致幻读/虚读、不可重复读。
oracle默认的隔离级别 - 可重复读：一个事务执行过程中看到的数据总是一致的。可以解决脏读、不可重复读。
mysql默认的隔离级别。 - 串行化：读会加读锁，写会加写锁，所有操作都是串行的。可以解决脏读、幻读/虚读、不可重复读。
LBCC和MVCC
InnoDB默认级别时可重复读（Repeatable Read），为了解决该隔离级别下的幻读问题，提出了LBCC和MVCC
LBCC为了解决当前读情况下的幻读。
MVCC为了解决普通读（快照读）的幻读。
当前读：Locking Read 锁定读，读取当前数据的最新版本，并对这个数据加锁，防止别的事务更改来解决当前读的问题。在进行写操作的时候就需要进行当前读，读取数据记录的最新版本。
快照读：Read View，在可重复读隔离级别下，我们可以把每次select当作一次快照读
LBCC：Lock-Based Concurrent Control基于锁的并发控制
MVCC：Multi-Version Concurrent Control基于多版本的并发控制
问答
mysql隔离级别为什么默认可重复读？
因为Mysql的binlog日志的格式在5.0之前，只有statement模式，记录的是修改sql语句，如果mysql默认隔离级别为读提交，主从同步会出现数据不一致的bug。
例：
A提交事务为删除id>10的，B提交事务为insert一条id为11的数据，A在B提交后再提交。这时候master执行的顺序是先删后插，statement记录的是先插后删，slave同步到的binlog日志也是先插后删，这时候，主从同步不一致的bug就出来了。
推荐：
如果用mysql5.0+，隔离级别为读提交（Read commit），使用的是InnoDB引擎时，binlog日志模式推荐使用row模式
InnoDB引擎binlog日志有几种模式（Myisam引擎不支持事务）?
5.0之前只有statement，5.0之后有三种：
-
statement：记录的是修改sql语句。 -
row：记录的是每行实际数据的变更。 -
mixed：statement和row模式的混合。
