目录
如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下
ACID四个特性：
1、原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
2、一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
3、隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
MySQL标准的事务隔离级别包括：
1. 读未提交（read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到。
2. 读已提交（read committed）：一个事务提交之后，它做的变更才会被其他事务看到（为什么有些产商会把隔离级别设置成这个？）。
3. 可重复读（repeatable read）：默认（为什么默认是这个？），一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
4. 串行化（serializable ）：对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
Oracle标准的事务隔离级别包括：
1. 读已提交（read committed）：默认隔离级别。
2. 串行化（serializable ）
4、持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
多个事务同时执行可能出现的问题
1. 脏读：一个数据行的读取中，读到别的事务更改的未提交的数据（若其他事务回退，那么它之前读的就是假的）
2. 不可重复读：（同一个数据项）多次读取过程中，读到其他事务提交的数据，导致读取的结果前后不一样（因为每次读取都是获得S锁然后读完立即释放，导致下一次读取的过程中可能其他事务已经进行了获取X锁并提交事务的操作导致数据被修改了）
3. 虚读/幻读：一批数据整体（比如数据的个数count）多次读取过程中，其他事务插入或者删除了新数据并提交，导致前后读出的结果不一样、（前面的结果好像幻想出来的）
隔离级别内在原理（虚拟锁版）
排他锁(Exclusive Lock)：简称X锁，用于写数据。X锁一次只能有一个事务获取，X锁被获取的时候其他事务不能获取S锁
共享锁(Share lock)：简称S锁，用于读数据。S锁可被多个事务获取，S锁被获取的时候其他事务不能获取X锁
下面介绍不同的隔离场景下其底层使用的X锁与S锁（虚拟锁）的特点：
1. 读未提交：写数据时加上X锁，直到事务结束，读的时候不加锁
虽然能够避免丢失数据， 但是可以读到没有提交或者回滚的内容 （脏数据）， 这其实就是数据库最低的事务隔离级别
2. 读已提交：写数据的时候加上X锁，直到事务结束，读的时候加上S锁，读完数据立刻释放
这能避免“丢失数据”和“脏数据”，但是会出现“不可重复读”的问题，这是第二级的事务隔离级别
3. 可重复读：写数据的时候加上X锁，直到事务结束，读数据的时候加S锁，直到事务结束（底层使用一致性视图(read-view)用于记录每个事务的操作）
这能避免“丢失数据”和“脏数据”，“不可重复读”三个问题，这是Mysql默认的隔离级别
InnoDB中的Repeatable Reads可以通过next-key lock解决RR的幻读问题。
4. 串行化：以上方法都无法解决幻读（Innodb可以解决），唯有加上串行化
实现串行执行，也就是同一时间只有一个人在操作数据库，其他人只能等待直至其结束。代价很高
需要注意的是，这是标准事务隔离级别的定义。在MySQL的innodb引擎中，在可重复读级别下，通过mvcc解决了幻读的问题。
隔离级别内在原理（视图）
在MySQL里，有两个“视图”的概念：
1. 一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view … ，而它的查询方法与表一样。
2. 另一个是InnoDB在实现MVCC（数据库的多版本并发控制）时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读已提交）和RR（Repeatable Read，可重复读）隔离级别的实现。
在使用事务时：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用start transaction with consistent snapshot 这个命令。
对于读已提交与可重复读，它们在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。
- 读未提交：直接返回记录上的最新值，没有视图概念
- 读已提交：在每个SQL语句开始执行的时候创建视图
- 可重复读：在事务启动时（start transaction with consistent snapshot）创建视图（这个快照是基于整库的）（注意，如果只是简单的begin语句，那么事务的创建是在执行第一条sql语句时才创建的）
- InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。
- 而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。InnoDB利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。
- 也就是说，数据表中的一行记录，其实可能有多个版本(row)，每个版本有自己的row trx_id。
- 上图三个虚线箭头，就是undo log；而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来。
- 在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前“启动了但还没提交”的所有事务ID。
- 数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）
- 对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：
-
如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
-
如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
-
如果落在黄色部分，那就包括两种情况
a. 若 row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；
b. 若 row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。
-
- 详细示例介绍可查看这里
- 总结，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
-
版本未提交，不可见；
-
版本已提交，但是是在视图创建后提交的，不可见（注意如果当前操作涉及当前读(insert/update)，那么其必须读到已提交的数据版本）；
-
版本已提交，而且是在视图创建前提交的，可见。
-
- 串行化：直接用加锁的方式来避免并行访问
当前读与快照读
快照读：普通的select语句，读取的是记录数据的可见版本（可能是过期的数据），不用加锁
当前读：使用insert/update语句，或者带锁的select语句，读取的是记录数据的最新版本，并且当前读返回的记录都会加上锁，保证其他事务不会再并发的修改这条记录
总的来说，存在即合理，每个隔离级别都有它自己的使用场景，需要根据自己的业务情况来定。比如我们下面举一个“可重复读”适用的的案例场景
假设你在管理一个个人银行账户表。一个表存了每个月月底的余额，一个表存了账单明细。这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。
这时候使用“可重复读”隔离级别就很方便。事务启动时的视图可以认为是静态的，不受其他事务更新的影响。
375
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
