mysql中事务处理那点事

1事务隔离级别

事务有ACID特性：

A:atomicity 原子性 要么都操作成功，要么就都失败。只有查询的事务很容易处理原子性，但是有更新和插入动作的事务，就要注意并发对这部分数据的影响了。

 

C:consistency 一致性 当某一个字段是表的唯一标示时，如果事务修改了这个标示并破坏了表唯一性，那么系统可以自动撤销事务的这个动作。

 

I:isolation 隔离性 隔离性也可以叫做并发控制 concurrency control 可串行化 serializability 锁 locking  也就是说呢很多歌事务一起提交的时候彼此是看不到对方的，其也是基于一个粗粒度的锁机制 granular lock 所以就会有某数据库支持行锁，表锁等

 

D:durability 持久性 事务一旦提交就一定是永久性保存的，即使发生宕机，数据库也是可以恢复的，但是这只是事务系统的保证，并不会衍生到硬件级别的。也就是说，持久性是保证事务系统的高可靠性 high reliability 不是高可用性 high availability，例如raid卡坏了和自然灾害就没法通过持久性来保证数据还在了。

 

事务的分类：

扁平事务 flat transactions 这种事务在一般系统中使用率很高，我写的ostocyjshop基本都是，很简单很好懂。但是对于分阶段进行的业务就不适用扁平事务了，因为回滚的代价太高了。

 

带有保存点的扁平事务 flat transactions with savepoints 当使用begin work 开启一个事务时都会默认加入一个保存点，保存点的计数是延续的，不会因为回滚到某个点而重新计数。

 

链事务：chained transactions 是保存点事务的一个变体，由于保存点是容易丢失的 volatile 不是 persistent的，所以当恢复保存点时，事务不能从最近的一个保存点继续执行了，必须重新执行了。链事务的意思是：一个事务开始时，释放不需要的数据对象，将上下文处理传递给下一个事务，形成一个原子性的合并事务。下一个事务是知道上一个事务的结果的，当这个合并事务需要被回滚时，只能回滚到最近的一个保存点，链事务在提交后释放持有的锁，但是保存点事务会一直持有从头到尾所有点的锁。（应该是这个意思）

 

嵌套事务 nested transactions 你可以理解成一个树结构，有一个根控制着所有的节点，节点控制叶子。根只能控制节点的逻辑，而无法触及叶子的行为。叶子的行为交由节点来控制。叶子可以是一个子事务，提交给节点，但是效果并不会反映到db中，必须根提交了事务才会把所有节点的事务反映到db中。如果叶子中有事务失败，那么所有事务都要回滚。嵌套事务是可以用保存点事务来模拟的，但是锁的控制上相对复杂。要真正的实现并发事务处理，还是需要db支持嵌套事务的。

 

分布式事务 distributed transactions 及扁平事务分布在网络节点中。mysql的innodb引擎无法支持并行事务，可以用保存点事务模拟。

 

事务的隔离级别

READ UNCOMMITTED  对事务来说叫做浏览访问 browse access

READ COMMITTED 在mysql5.0前对于这种事务隔离下，会造成master和slave的不一致问题，主要问题还是记录sql和表变化的日志文件的格式是statement而不是row的，也就是非行级别而是语句级别的。但在mysql5.1后都是row级别了，不会有不一致问题。

REPEATABLE READ 是mysql inndb引擎的默认事务级别

SERIALIZABLE  主要用于innodb存储引擎在分布式环境下的事务隔离级别

 

 

未授权读取

也称为读未提交（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

授权读取

，也称为读提交（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止（延缓）其他事务访问（写）该行。

可重复读取

可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

序列化

序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。