事务的四大特性和隔离级别

1.事务的四大特性(ACID)：指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

1.1 原子性（Atomicity）

第一个原子性，这个是最简单的。说的是一个事物内所有操作共同组成一个原子包，要么全部成功，要么全部失败。这是最基本的特性，保证了因为一些其他因素导致数据库异常，或者宕机。

1.2 一致性（Consistency）

第二一致性，这个是大家误解最深的，很多博客都喜欢用银行转账的例子来讲一直性，所谓的一致性是基于原子性。

原子性只保证了一个事物内的所有操作同一性，大家同生死，不会出现你死了，我还活着。但是，原子性并没有保证大家同一时刻一起生，一起死。计算机指令是有先后顺序的，这样就决定了一个事物的提交，会经历一个时间过程，那么如果事物提交进行到了一半，我读取了数据库，会不会读到中间结果？

为了防止这样的情况，数据库事物的一致性就规定了事物提交前后，永远只可能存在事物提交前的状态和事物提交后的状态，从一个一致性的状态到另一个一致性状态，而不可能出现中间的过程态。也就是说事物的执行结果是量子化状态，而不是线性状态。

数据库提交事物会有一个过程，如果提交的时候，存在一个时间差，在提交的第一秒，一个删除过程还没完成到了第三秒才完成，会不会第一秒访问的人和第三秒访问的人得到不同的结果？出现不一致，状态的混沌？这就是一致性得保证的只会有前状态和后状态，绝不会出现中间态。

1.3 隔离性（Isolation）

事物的隔离性，基于原子性和一致性，因为事物是原子化，量子化的，所以，事物可以有多个原子包的形式并发执行，但是，每个事物互不干扰。

但是，由于多个事物可能操作同一个资源，不同的事物为了保证隔离性，会有很多锁方案，当然这是数据库的实现，他们怎么实现的，我们不必深究。

1.4持久性（Durability）

持久性，当一个事物提交之后，数据库状态永远的发生了改变，这个事物只要提交了，哪怕提交后宕机，他也确确实实的提交了，不会出现因为

刚刚宕机了而让提交不生效，是要事物提交，他就像洗不掉的纹身，永远的固化了，除非你毁了硬盘。

2.不考虑隔离性可能产生的问题

 

现在重点说明下事务的隔离性，当多个线程（或多个客户端）都开启事务操作数据库中的数据时，数据库系统要能进行隔离操作，以保证各个线程获取数据的准确性。

 

如果不考虑事务的隔离性，会发生的几种问题：

 

2.1 脏读

 

脏读是指在一个事务处理过程中读取了另一个未提交的事务中的数据。

 

2.2 不可重复读

 

不可重复读是指对于数据库中的某个数据，一个事务内多次查询却返回了不同的数据值，这是由于在事务执行过程中，数据被另一个事务修改并提交了。

 

2.3 幻读

 

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

 

幻读和不可重复读都是读取了另一条已经提交的事务，所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据（比如数据的个数）。

 

3.事务的隔离级别

3.1 read uncommitted : 读取尚未提交的数据 ：哪个问题都不能解决

3.2 read committed：读取已经提交的数据 ：可以解决脏读 ---- oracle、sql server、postgresql 默认的

3.3 repeatable read：重读读取：可以解决脏读 和 不可重复读 ---mysql默认的

3.4 serializable：串行化：可以解决 脏读 不可重复读 和 虚读---相当于锁表

以上四种隔离级别最高的是Serializable，最低的是Read uncommitted级别。当然，隔离级别越高，执行效率就越低。

 

01：Mysql的默认隔离级别是：可重复读：Repeatable read;

02：oracle数据库中，只支持seralizable(串行化)级别和Read committed();默认的是Read committed级别；

下面就四种隔离级别进行场景设计：

01: Read uncommitted 读未提交; 公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。

02:Read committed 读已提交; singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......

03:Repeatable read 重复读 当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。

04：重复读可能出现幻读： singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出现了幻觉，幻读就这样产生了。

Serializabale:最高的事务隔离级别，代价花费最高，性能很低，很少使用，在此级别下，事务顺序执行，避免上述产生的情况。