1.1READ UNCOMMITTE（读未提交）

1.设置为读未提交

SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

2.查看隔离级别

SELECT @@tx_isolation;

3.session A开启事务TA 执行插入操作

4.在另一个session B的事务TB中查询数据

5.此时如果TA执行ROLLBACK; 回滚数据， 

6.TB再次查询无结果。

根据测试结果可以看到，TB如果第一次查询获取到TA中尚未提交的数据，之后TA又回滚了数据，会造成读脏数据。

如果要避免读脏数据，至少要把事务隔离级别设为：1.2 READ COMMITTED（读已提交）

由于读未提交的隔离级别很低，在并发情况下，数据一致性并不能得到保证。但它也并非一无是处，至少事务帮我们保证了原子性，持久性。下面看一下MySql怎么做到这些的。

InnoDB表中除了每个字段的值，还包含了一些隐藏信息： DELETE BIT，DB_TRX_ID，DB_ROLL_PTR，DB_ROW_ID

DELETE BIT位用于标记该记录是否被删除，被标记的数据在commit时才真正被删除

6字节的DB_TRX_ID，系统版本号， 每开启一个事务，系统版本号都会自动递增

7字节的DB_ROLL_PTR 指向当前记录项的Undo log记录，回滚时通过这个指针找到历史数据

6字节的DB_ROW_ID，当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，否则聚集索引中不包括这个值，这个用于索引当中

重点关注DELETE BIT，DB_TRX_ID，DB_ROLL_PTR，下图表示某表中的一条数据，

Undo log存放在表空间中，作用是保存各个事务操作数据库的历史，用于回滚。Undo log分insert和update两类，因为insert时，原始的数据并不存在，所以回滚时把insert Undo log的数据丢弃即可，而update Undo log则必须遵守以下过程。

一下是事务T2再次提交时，发生的改变，Undo log增加了上一版本数据的备份，Undo log不会一直变大，

MySql的purge线程会把当前最早开启的事务之前的Undo log清除。

由此可见事务提交时InnoDB什么都不需要做，如果回滚，需要从Undo log中恢复数据，Undo log中数据越多恢复事件就越长，InnoDB提交的效率要比回滚高。

上文提到了Redo log，它和Undo log相反，Redo log记录的是新数据的备份。在事务提交前，只要将Redo log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo log已经持久化。Redo log与Undo log另一个区别在于它在磁盘上作为一个独立的log文件存在。系统可以根据Redo log的内容，将所有数据恢复到最新的状态。

实际上数据写到磁盘是一个复杂的过程，并不仅仅记录了Redo log，为了提高性能，减少IO次数，做了很多缓冲处理，下面做个记录带研究：

1.InnoDB buffer pool， Redo log buffer。这个是InnoDB应用系统本身的缓冲。

2.page cache /Buffer cache（可通过o_direct绕过）。这个是vfs层的缓冲。

3.Inode cache/directory buffer。这个也是vfs层的缓冲。需要通过O_SYNC或者fsync()来刷新。

4.Write-Back buffer。(可设置存储控制器参数绕过)

5.Disk on-borad buffer。(可通过设置磁盘控制器参数绕过)

数据何时写入磁盘也有多种可能性：

1.已提交的数据，写入到数据文件，这种是正常情况。

2.数据已经提交，但是还没有写入数据文件，这种情况可能是正在写，也可能是异常停机，数据会根据Redo log写入磁盘。

3.数据没有提交，但是已经写入到数据文件，出现检查点，数据缓冲区空间不够等情况。

如果出现上述第三种情况，也并不会出现异常，

在redo buffer和undo中对该事务都有一个是否提交的标记。两者的默认状态都是active的，即没有提交时刻处于激活状态，commit成功后，redo buffer信息全部写入redo file，同时修改两者中的事务提交标识为inactive。未commit的话，事务依旧是active，所以数据即使被提前写入了数据文件也没关系。

参考：

http://blog.csdn.net/longxibendi/article/details/39835185