数据库理论_事务&并发控制_001

事务：用户定义的一组数据库操作序列。这些操作要么都做要么都不做，它是一个不可分割的工作单元。

 

事务的特性：(ACID)

原子性(Atommicity)、一致性(Consistency)、隔离性(Isolation)、持续性(Durability)

原子性：事务是数据库的逻辑操作单元，事务中的操作要么都做要么都不做。

         所谓逻辑操作单元，我是这样理解的。我们都知道数据库是由多张表组成的，表中存的自然都是数据。但是数据与数据之间其实是存在逻辑关系的。最经典的一个例子，银行账号。假如，我在某银行有两张卡，A和B。A里面有10万，B里面有10万。我名下就有20万块钱。接着假如，我今天抽风，我从A里面转出了5万到B里面。那么这个事务可以抽象成两个操作。

      1.A卡里面的钱要减少五万。A=100000-50000=50000 

      2.B卡里面的钱要增加五万。B=100000 + 50000 = 15000

     如果只做了操作1。A：5万，B: 10万。我平白无故少了5万，那我肯定不干。如果只做了操作2。我平白多了5万，我是很愿意的，银行肯定也不干。

  这就是事务的原子性，要么都做，要么都不做。逻辑上不可分割。数据库里的数据毕竟都是有现实存在意义的，不能随便乱改。

 

一致性：事务执行的结果必须使数据库从一个一致性状态变成另一个一致性状态。还是以上面的例子来解释，事务之前：A 10万， B 10万。我有20万存在某行。这是一个一致性状态。 事务之后： A 5万  B 15万 我还是有20万。我与银行都不吃亏。数据库变到了另一个一致性的状态。（我觉得一致性状态可以把它理解为正确的、合理的状态。数据库的数据是随时可以变化的，但是它得变得有意义，变得合理。乱七八糟地瞎改，那是黑客干的事，是要被关起来反思哒。）

 

隔离性：就是一个事务的执行不能被其他事务干扰。其实说白了还是为了保证事务的原子性和一致性。

 

持续性：有的书也会把它翻译成持久性。就是指事务一旦成功提交，它对数据库的数据的更新是持久的。如果不持久，那也没有改的必要嘛。

 

事务的并发： 理论上来讲，如果串行执行多个事务的话，N个事务排队执行，T1完了T2,T2完了T3.....这样一个接着一个，就可以很好的保证事务的ACID特性了。但是万事万物都是两面的，这样做的一大代价就是资源浪费。其实每个事务在不同的操作过程中可能需要的资源不一样，有时候需要CPU，有时候要存取数据库，有时候要通信等。浪费了资源就响应慢了，响应慢了用户就不干了。这样，事务的并发就应运而生啦。

T1->T2->T3： 这是串行。

T1(A)->T1(B)->T2(A)->T3(A)->T3(B)->T2(B)->T3(C): 并行执行。将事务切片，交叉并发执行。

事务的并发说白了就是节约系统资源，快速执行，减少用户等待响应的事件。但是它破坏了事务的一致性和隔离性，所以就产生了以下的问题。

 

数据库并发引起的三种数据不一致性。老是傻傻记不清，再来复习一遍吧。

1. 丢失修改。

事务T1和T2同时修改数据A,此时A=12，T1: A=A-1, T2: A=A-1, T1提交，T2提交。T1和T2都对T1做了减1的操作，但是T1被T2覆盖。

 

2.不可重复读。

事务T1在操作1和操作2都需要读取某个数据A，在操作1结束后，T2中的操作修改了数据A。使得T1在后续操作中再次读取到的数据A和之前的不一致。也就是T1中第一次读取的数据A不可重复读。

 

3.脏数据。

T1修改了某个数据A并将其写入了磁盘。T2读取了新的A,接着T1发现自己刚才抽风了不应该修改A，就回滚了刚刚的操作。这个时候T2悲剧了，因为你读的数据是错哒哒哒，肿么办？这就是脏读。