最近都在看数据库的相关，然后就有看到事务，看了很多文章发现内容多，有些地方容易混淆，不做笔记还真不行，必须总结。
概念怎么说？至少了解一波吧
事务可以理解为一个 独立的工作单元, 在这个独立的工作单元中, 有一组操作;放在事务(独立工作单元)中的多个操作, 要么全部执行成功, 要么全部执行失败。
ACID（事务四大特性）
-
原子性（Atomicity）
一个事务必须被视为一个不可分割的最小工作单元, 整个事务中的所有操作要么全部提交成功, 要么全部失败回滚。对于一个事务来说, 不能只成功执行其中的一部分操作, 这就是事务的原子性。 -
一致性（Consistency）- 虽然可数据表中的数据可能一直在变化, 但是事务的一致性特性会保证 数据库总是从一个一致性的状态 转换到 另一个一致性的状态;
- 比如一个转账的例子 A初始200 ，B初始300，A给B转100。
转账前的一致性状态是: ‘A’(余额200), ‘B’(余额300)
转账成功后的一致性状态是: ‘A’(余额100), ‘B’(余额400)
转账如果失败的话, 一致性的状态应该回滚到转账前的状态: ‘A’(余额200), ‘B’(余额300) -
隔离性（Isolation）- 隔离性是当多个用户
并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 - 事务有四种隔离级别
(从低到高: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE)
- 隔离性是当多个用户
-
持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
为什么要设置隔离级别？
在数据库操作中，在并发的情况下可能出现如下问题：
-
更新丢失（Lost update）
如果多个线程操作，基于同一个查询结构对表中的记录进行修改，那么后修改的记录将会覆盖前面修改的记录，前面的修改就丢失掉了，这就叫做更新丢失。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。（A）第一类：事务A撤销
回滚时，把已经提交的事务B的更新数据覆盖了。
在数据库的隔离级别里，该类的丢失更新不会出现（B）第二类：事务A覆盖事务B已经提交的数据，造成事务B所做的操作丢失。。
此类更新丢失问题, 无法依靠前三种隔离级别来解决, 只能用最高隔离级别 Serializable 或者手动使用乐观锁, 悲观锁来解决。 -
脏读（Dirty Reads）
A事务读取B事务尚未提交的数据并在此基础上操作，而B事务执行回滚，那么A读取到的数据就是脏数据。
在常见数据库中, 事务已经用自身特性（隔离性的 – REPEATABLE READ或以上隔离级别）解决了这个问题;
READ COMMITED级别保证了, 只要是当前语句执行前已经提交的数据都是可见的。注意和REPEATABLE READ级别的区!!! -
不可重复读（Non-repeatable Reads）
- 假设现在上面的
脏读问题已经被完全解决了, 那就意味着事务中每次读取到的数据都是持久性的数据(被别的事务最终 提交/回滚 完成后的数据)。 - 但是你还需要知道的是: 解决了脏读问题, 只是能保证你在事务中每次读到的数据都是持久性的数据而已!!!
- 如果在一个事务中
多次读取同一个数据, 正好在两次读取之间, 另外一个事务确实已经完成了对该数据的修改并提交, 那问题就来了: 可能会出现多次读取结果不一致的现象。
在常见数据库中, 事务已经用自身特性（隔离性的 – REPEATABLE READ或以上隔离级别）解决了这个问题;
REPEATABLE READ级别保证了, 只要是当前事务执行前已经提交的数据都是可见的。注意和READ COMMITED级别的区!!! - 假设现在上面的
-
幻象读
- 容易搞混
不可重复读和幻读，都是说两次读取数据不一致。 - 但
不可重复读主要是说多次读取一条记录, 发现该记录中某些列值被修改过。 - 而
幻读主要是说多次读取一个范围内的记录(包括直接查询所有记录结果或者做聚合统计), 发现结果不一致(标准档案一般指记录增多（一般来讲）, 记录的减少应该也算是幻读（猜测）)。
指两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中。通俗的讲，一个线程中的事务读取到了另外一个事务insert的数据。
在常见数据库中, 事务已经用自身特性（隔离性的 – SERIALIZABLE）解决了这个问题。但是该隔离级别，一般不常用，高并发效率太低
比如Mysql Innodb 引擎在隔离级别为REPEATABLE READ（可重复读）下，一般使用MVCC多版本控制来解决幻读问题。
MySQL-InnoDB-MVCC多版本并发控制
MySQL innodb 引擎如何解决幻读 - 容易搞混
事务的隔离级别
上面有提到，这里再次列出，加深影响。事务的隔离级别有四种，由低到高依次
- Read uncommitted (未授权读取、读未提交)
- Read committed（授权读取、读提交）
- Repeatable read（可重复读取）
- Serializable（序列化）
隔离级别高的数据库的可靠性高，但并发量低，而隔离级别低的数据库可靠性低，但并发量高，系统开销小。
READ UNCIMMITTED (未提交读)
如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。
该隔离级别可以通过排他写锁实现。这样就避免了更新丢失，却可能出现脏读。也就是说事务B读取到了事务A未提交的数据
ep:
一个售票系统，A和B是售票员，他们分别是两个不同窗口的员工，现在售票系统只剩下3张票，此时小明来A这里买3张票，小张来B买票，A查到余票还有就给接了订单，就要执行第三步的时候，B接到小张的请求查询有没有余票。B看到A卖出了3张票，于是拒绝卖票。但是A系统出了问题，第三步执行失败，数据库为保证原子性，数据进行了回滚，也就是说一张票都没卖出去。
总结:这就是事务还没提交，而别的事务可以看到他其中修改的数据的后果，也就是脏读。
READ CIMMITTED (提交读)
读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
该隔离级别避免了脏读，但是却可能出现不可重复读。事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
大多数数据库系统的默认隔离级别是READ CIMMITTED。
ep:
还是A和B销售员，余票4张，小明来A请求3张订票单，A受订单，要卖出3张票，上面的销售步骤执行中的时候，小张也来B那里买票，由于A的销售事务执行到一半，B事务没有看到A的事务执行，读到的票数是3，准备接受订单的时候，A的销售事务完成了，此时B的系统变成显示0张票，此时只能拒绝订单了。
总结:这就是A的事务执行到一半，而B看不到他执行的操作，所以看到的是旧数据，也就是不可重复读。
Repeatable Read(可重复读)
可重复读是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。
在第一个事务中的两次读数据之间，即使第二个事务对数据进行修改，第一个事务两次读到的的数据是一样的。这样就发生了在一个事务内两次读到的数据是一样的，因此称为是可重复读。
读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。这样避免了不可重复读取和脏读，但是有时可能出现幻象读。（读取数据的事务）这可以通过“共享读锁”和“排他写锁”实现。
ep:
销售部门有规定，如果销售记录低于规定的值，要扣工资，此时经理在后端控制台查看了一下小明的销售记录，发现销售记录达不到规定的次数，心里暗喜，准备打印好销售清单，理直气壮和小明提出，没想到打印出来的时候发现销售清单里面销售数量增多了几条，刚刚好达到要求，气的经理撕了清单纸。原来是小明在就要打印的瞬间卖出了几张票，因此避过了减工资的血光之灾。
虽然读取同一条数据可以保证一致性，但是却不能保证没有插入新的数据,就是幻读。
Serializable（串行读）
提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。
如果仅仅通过行级锁是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。序列化是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻读。
对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。MySQL的默认隔离级别就是Repeatable read。