什么是事务
事务是并发控制的基本单位。所谓的事务，是一个操作序列，这些操作要么都执行，要么都不执行，是一个不可分割的工作单位。比如银行转账，从一个账号扣款并使另一个账号增款，这两个操作要么都执行，要么都不执行。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保证数据一致性。
事务的4个基本特征ACID
原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后状态是一样的。
举个例子：假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
关于事务的隔离性数据库提供了四中隔离级别。
持久性（Durability）
持久性表示一个事务一旦被提交了，那么对数据库中的数据的改变是永久的，即便是数据库系统遇到故障，也不会丢失。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
不考虑隔离性会出现的几种情况
脏读
脏读是指一个事务处理过程中读到了另一个事务未提交的数据
问题出在哪里呢？其实是一个事务在写的时候，另一个事务进来读取数据。
例子：用户A向B转账100元
update account set money=money+100 where name=’B’; (此时A通知B)
update account set money=money - 100 where name=’A’;
当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。所以这种读取是不可靠的。
不可重复读
不可重复读是指在对于数据库的某个数据，一个事务范围内多次查询却返回了不同的数据值。这是由于在查询间隔，被另一个事务修改并提交了。
问题出在哪里呢？其实是在一个事务读的时候，另一个事务进来修改数据库。
例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。
不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。
在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。
幻读
幻读是指当事务不是独立执行时发生的一种现象。例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
更新丢失
多个事务同时读取某一数据，一个事务成功处理好了数据，被另一个事务写回原值，造成第一个事务更新丢失。
事务的隔离级别
READ UNCOMMITTED-读未提交
Read UnCommitted事务可以读取事务已修改，但未提交的的记录。
Read UnCommitted事务会产生脏读（Dirty Read）。
Read UnCommitted事务与select语句加nolock的效果一样，它是所有隔离级别中限制最少的。
本栗子来源于数据库事务隔离级别
公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。
READ COMMITTED-读提交
Read Committed只可以防止脏读。
我们看Read Uncommitted问题出现在哪里呢，为什么会出现脏读呢，是一个事务还没有提交，另一个事务就对其读取，就读取到了未提交的内容啦
Read Committed就不会出现此问题，未提交的数据是不允许读的，只能读取已提交的数据，那这样就没有问题了吗？No，这样会产生不可重复读。
singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在 singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......
出现上述情况，即我们所说的不可重复读 ，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
当隔离级别设置为Read committed 时，避免了脏读，但是可能会造成不可重复读。
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。
REPEATABLE READ-重复读
REPEATABLE READ事务不会产生脏读，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。
我们看Read Committed问题出在哪里呢，是一个事务A已经对数据进行了读取（虽然还没有修改），这个事务还没有结束，然后另一个事务B对此数据进行了修改，这就产生了A事务还没有结束时再次读取同一数据出现和起初读取数据不同的情况。
当隔离级别设置为Repeatable read 时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。
虽然Repeatable read避免了不可重复读，但还有可能出现幻读 。
REPEATABLE READ事务在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。其它事务仍可以插入新记录，但必须符合当前事务的搜索条件——这意味着当前事务重新查询记录时，会产生幻读（Phantom Read）。
singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额 （select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出 现了幻觉，幻读就这样产生了。
注：Mysql的默认隔离级别就是Repeatable read。
SERIALIZABLE-序列化
SERIALIZABLE可以防止除更新丢失外所有的一致性问题,即:
1.语句无法读取其它事务已修改但未提交的记录。
2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。
3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。
SNAPSHOT
Snapshot事务中任何语句所读取的记录，都是事务启动时的数据。
这相当于事务启动时，数据库为事务生成了一份专用“快照”。在当前事务中看到不其它事务在当前事务启动之后所进行的数据修改。
Snapshot事务不会读取记录时要求锁定，读取记录的Snapshot事务不会锁住其它事务写入记录，写入记录的事务也不会锁住Snapshot事务读取数据。
