事务的并发问题

• 脏读（Dirty read）：当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
• 失修改（Lost to modify）：指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
• 不可重复读（Unrepeatableread）：指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
• 幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

事务隔离级别

MySQL默认的事务隔离级别是可重复读(Repeatable Read)。

Oracle，SqlServer中都是选择读已提交(Read Commited)作为默认的隔离级别。

我们在项目中一般用读已提交(Read Commited)这个隔离级别。

为什么MySQL默认是可重复读（RR）级别

这个是有历史原因的，当然要从我们的主从复制开始讲起了！

主从复制，是基于什么复制的？是基于binlog复制的，简单理解为binlog是一个记录数据库更改的文件。

binlog有几种格式？

• statement:记录的是修改SQL语句
• row：记录的是每行实际数据的变更
• mixed：statement和row模式的混合

那MySQL在5.0这个版本以前，binlog只支持STATEMENT这种格式！而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，因此MySQL将可重复读(Repeatable Read)作为默认的隔离级别！

首先我们创建一个表table并插入一些数据：

CREATE TABLE tem_table(
	b1 int,
	b2 int
)

把自动提交关闭 执行两个会话：

此时查看会话1的提交结果：

dba> select * from t1;

+------+------+

| b1   | b2   |

+------+------+

|    1 |    4 |

|    2 |    8 |

|    3 |    4 |

|    4 |    8 |

|    5 |    4 |

+------+------+

5 rows in set (0.00 sec)

为什么项目中选读已提交(Read Commited)作为事务隔离级别