数据库设计之事务

数据库设计之事务

作为基础数据库理论之一的事务有必要好好整理学习一下！

一、什么是数据库的事务

数据库事务是指作为单个逻辑工作单元执行的一系列操作。

设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作：

　　· 更新客户所购商品的库存信息

　　· 保存客户付款信息--可能包括与银行系统的交互

　　· 生成订单并且保存到数据库中

　　· 更新用户相关信息，例如购物数量等等

　　正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了 差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比 如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态--库存信息没有被更新、用户也没有付款，订单也没有生成。 否则，数据库的信息将会一片混乱而不可预测。

　　数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。

PS：数据库事务就是为了避免出现这样的 在一次业务请求的过程中出现哪一步有问题了而保证数据的完整与一致性而设计出来的

有的时候一个业务要求可能需要同时更新多个表的内容，这个时候就需要用到事务来维持这样的一致性！

 

二、数据库事务的ACID属性

ACID，是指在（）中所具有的四个特性：原子性（Atomicity）、一致性 （Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）

　　事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么 全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性：

　　· 原子性

事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。

PS：我们可以将一次用户业务处理看成是一个原子性操作。里面如果有多条SQL语句的时候只有全部通过了才会一次性全部提交过去否则就不会提交而是回滚

　　· 一致性

事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时， 所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转 帐的应用程序时，应避免在转帐过程中任意移动小数点。

PS：在设计数据库的时候有的时候考虑了外键。通过外键可以做强制性约束处理。而这种约束就是为了保持数据的一致性！即如果A与B表 有外键而且是以A表中的ID字段为外键现在有这种约束。将A表中一条记录删除就会影响到B表！这就是一致性

　　· 隔离性

由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是 另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始 事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由 于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。

PS：在多线程程序的时候在共享区就会有这种隔离性。即一个线程对某公共资源的修改会上锁然他的线程就不能动它了。只能看到它原始的内容与修改完的内容，对于其中间的过程是不知道的！

 

　　· 持久性

　　 事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。

PS：即做过了事情就不可恢复！一旦提交就没办法了！

 

三、事务并发处理会产生的问题    
1,丢失更新  
     当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题、 每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。  
 PS：假设有两个事务同时对一条记录更新。其中事务一将字段A变更为1 然后事务二又过来将字段A变更为2.这样事务一的变更效果就没有了。这样就出现了丢失更新！
2,脏读  
     当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。  
     第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。  
 PS：情况与上面的类似
3,不可重复读  
      当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。  不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。  然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。  
 
4,幻像读  
      当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。  事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。

PS：假设事务A正在读记录一。第一次读到了第二次过来结果正好被事务B给删除掉了

导致事务A过了一会发现这条记录不见了。这就是幻像读的情况出现了

 

 

 

四、事务处理类型  

1,自动处理事务  
  系统默认每个T－SQL命令都是事务处理    由系统自动开始并提交  
 
2,隐式事务  
      当有大量的DDL  和DML命令执行时会自动开始，并一直保持到用户明确提交为止，切换隐式事务可以用SET  IMPLICIT_TRANSACTIONS    为连接设置隐性事务模式.当设置为  ON  时，SET  IMPLICIT_TRANSACTIONS  将连接设置为隐性事务模式。当设置为  OFF  时，则使连接返回到自动提交事务模式   
 
3,用户定义事务  
    由用户来控制事务的开始和结束    

命令有:  begin  tran  commit  tran    rollback  tran  命令  
 PS：这个与程序实现有点相像哦！程序中也可以做这样的自动化提交操作的！
 
4,分布式事务  
  跨越多个服务器的事务称为分布式事务,sql  server  

可以由DTc  microsoft  distributed  transaction  coordinator  来支持处理分布式事务,可以使用  BEgin  distributed  transaction  命令启动一个分布式事务处理