数据库事务ACID理解，及事务隔离级别

I.事务的4大特性（ACID） 
原子性（Atomicity）：原子性是指事务是一个不可分割的工作单位，事务中的操作要么全部成功，要么全部失败。 
一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另外一个一致性状态。 
隔离性（Isolation）：多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。 
持久性（Durability）：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 
II.不考虑事务的隔离性可能引发的问题 
1.脏读： 一个事务读取了另外一个事务未提交的数据。 
2.不可重复读：不可重复读指在一个事务内读取表中的某一行数据，多次读取结果不同。 
3.幻读：虚读(幻读)是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。 
III.事务的隔离性设置语句 
1.Read uncommitted：一个事务可以读取另一个未提交事务的数据，脏读、不可重复度和幻读均不可避免。 
2.Read committed：一个事务要等另一个事务提交后才能读取数据，可避免脏读，不可重复度和幻读不可避免。 
3.Repeatable read：在开始读取数据（事务开启）时，不再允许修改操作（即不允许其他事务的update操作），可避免脏读和不可重复度，但无法避免幻读。 
4.Serializable ：最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。 
★注：大多数数据库默认的事务隔离级别是Read committed，比如Sql Server , Oracle。Mysql的默认隔离级别是Repeatable read。

---

事务具有4大特性，一般称为事务的ACID属性：

原子性：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行，在操作失败后不能对数据库中的数据有任何影响。

一致性：在事务开始和完成时，数据必须保持一致状态，这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构也必须是正确的。

隔离性：数据库系统提供一定的隔离级别，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然（注意：事务的隔离性是相对于两个事务而说的，两个事务独立执行互补干扰）。

持久性：事务完成后，它对数据的修改是永久的，即使出现系统故障也能保持的正确性。

在多个线程开启并发事务处理时，如果不考虑事务的隔离性，可能带来的问题：

脏读：

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条数据就会处于一个不一致的状态 ，这时候另一个事务也来读取同一条记录，如果不加控制，第二个事务就读取了这些“脏数据”。简单的点说：一个事务在处理过程中读取了另一个事务中未提交的数据。

如：用户A向用户B转账100元，对应SQL命令如下：

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再次读取该数据就得到了不同的结果，发送了不可重复读。

幻读：

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据。

如：事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

不可重复读和幻读的共同点是都是读取已经提交的数据，不同的是不可重复读是两个事务读取的同一条数据发现不同，而幻读是两条或者多条数据之间的问题。

数据库实现隔离级别的方式有两种：

在读取数据之前，对其加锁，阻止其他事务对数据进行修改；

不加锁，利用数据库提供的机制来避免这些问题的发生。

MySQL在处理事务隔离和并发之间的矛盾上提供了四种事务的隔离级别：

未提交读（Read uncommitted）：

最低级别，只能保证不读取物理上损坏的数据。两个事务，其中一个事务对数据做的DML操作还未提交，另一个事务能够立即看到。

如：老板给我发工资，先给我打了1W，还没提交事务，我发现账上已经有1W了，后面老板反悔了，说发多了，又更新为5K，我想买个iphone6s，发现钱不够了。

这样会产生严重的脏读，因为修改的事务也许在提交前还会有其他的很多修改，所以另一个事务的数据读取会错乱。

已提交读（Read committed）：

可以避免脏读的发生，是语句级别的。两个事务，其中一个事务对数据做的DML操作提交后，另一个事务才能看到。

如：还是上面的例子，老板给我打钱，中间反悔了不算，只有在最后确认了，最终发给我5K，那么我才能够看到账户里多了5K。

这避免了上面脏读的问题，但是这样还是会产生不可重复读，意思是两个事务同时开启，事务A读取数据后，事务B对数据进行修改后提交，事务A再次读取，会发现跟前一次读取的内容不一样了。

可重复读（Repeatable read）：

可以避免脏读和不可重复读的发生，是事务级别的。两个事务，其中事务A获取一条数据，事务B在事务A提交事务前无法操作这条数据，这样就保证了可以重复读。（即数据库加了读锁）

如：A读取一条数据，给它加锁，B无法修改这条数据；但是B可以往表中插入、删除数据。

避免了上面的问题，但是这样还是会产生幻读现象，意思是两个事务同时开启，事务A全表更新未提交事务，事务B做了插入操作提交，事务A在事务中发现全表更新并没有成功。

可序列化（Serializable）：

最高级别，事务级别，可避免脏读、不可重复读、幻读的发生。两个事务完全独立，其中一个事务做的操作，对于另外一个事务不产生任何影响。（数据库事务加了锁，所有事务串行执行）

可以避免上述所有问题，但是性能上影响很大。

以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。

在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)；而在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。

在MySQL数据库中查看当前事务的隔离级别的语句：

select @@tx_isolation;

在MySQL数据库中设置事务的隔离级别的语句：

set [glogal | session] transaction isolation level 隔离级别名称;

set tx_isolation=’隔离级别名称;

注意：

设置数据库的隔离级别一定要是在开启事务之前！如果是使用JDBC对数据库的事务设置隔离级别的话，也应该是在调用Connection对象的setAutoCommit(false)方法之前。调用Connection对象的setTransactionIsolation(level)即可设置当前链接的隔离级别。

隔离级别的设置只对当前链接有效。对于使用MySQL命令窗口而言，一个窗口就相当于一个链接，当前窗口设置的隔离级别只对当前窗口中的事务有效；对于JDBC操作数据库来说，一个Connection对象相当于一个链接，而对于Connection对象设置的隔离级别只对该Connection对象有效，与其他链接Connection对象无关。