备忘ACID，隔离级别等

事务

定义：用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。

例如,在关系数据库中,一个事务可以是一条SQL语句、一组SQL语句或整个程序。 事务ACID特性。 

ACID就是：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)。 

事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务,则由DBMS按缺省规定自动划分事务。在SQL语言中,定义事务的语句有三条： 

BEGIN TRANSACTION 

COMMIT 

ROLLBACK

原子性（ Atomicity ）：事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做 

一致性（ Consistency ）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态

隔离性（ Isolation ）：一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰（最容易出问题，脏读、幻读。。。）（

持续性（ Durability ）：一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。

事务的隔离级别

在并发情况下定义使用

1.读未提交（可以读取未提交的数据）--很少子啊应用程序中使用

一个事务读取了另一个事务修改了但未提交的数据（内存里面），脏读

2.读已提交（读取数据必须是已经提交）--多数数据库系统的默认隔离级别（但不是MySQL默认的）

第一次读取数据,再次读取时候（中间有其他事务更改了数据），导致这次数据和上次不一样

3.可重复读--MySQL的默认事务隔离级别

同一个事务里多次查询看到的数据都是一致的，但是会导致幻读。

个人理解：首先读未提交这个级别是很少在应用中使用的，因为它没能解决一个问题（脏读，重复读，幻读）；读已提交是大部分数据库的隔离级别，但不是mySql，这种隔离级别是只能读到已经提交的数据，但是幻读和不能重复读都是会发生的；重复读是Mysql默认的隔离级别，这种级别也不能阻止幻读的可能性；序列化是最高的级别了，所有的情况都会避免，但性能不好，因此也不会常用！

事务的传播行为

传播行为

含义

PROPAGATION_REQUIRED（XML文件中为REQUIRED)

表示当前方法必须在一个具有事务的上下文中运行，如有客户端有事务在进行，那么被调用端将在该事务中运行，否则的话重新开启一个事务。（如果被调用端发生异常，那么调用端和被调用端事务都将回滚）

PROPAGATION_SUPPORTS(XML文件中为SUPPORTS）

表示当前方法不必需要具有一个事务上下文，但是如果有一个事务的话，它也可以在这个事务中运行

PROPAGATION_MANDATORY(XML文件中为MANDATORY）

表示当前方法必须在一个事务中运行，如果没有事务，将抛出异常

PROPAGATION_NESTED(XML文件中为NESTED)

表示如果当前方法正有一个事务在运行中，则该方法应该运行在一个嵌套事务中，被嵌套的事务可以独立于被封装的事务中进行提交或者回滚。如果封装事务存在，并且外层事务抛出异常回滚，那么内层事务必须回滚，反之，内层事务并不影响外层事务。如果封装事务不存在，则同PROPAGATION_REQUIRED的一样

PROPAGATION_NEVER（XML文件中为NEVER)

表示当方法务不应该在一个事务中运行，如果存在一个事务，则抛出异常

PROPAGATION_REQUIRES_NEW(XML文件中为REQUIRES_NEW）

表示当前方法必须运行在它自己的事务中。一个新的事务将启动，而且如果有一个现有的事务在运行的话，则这个方法将在运行期被挂起，直到新的事务提交或者回滚才恢复执行。

PROPAGATION_NOT_SUPPORTED（XML文件中为NOT_SUPPORTED）

表示该方法不应该在一个事务中运行。如果有一个事务正在运行，他将在运行期被挂起，直到这个事务提交或者回滚才恢复执行

常用的锁

悲观锁：悲观锁的实现采用的数据库内部的锁机制，一个典型的倚赖数据库的悲观锁调用：

select * from account where name=”张三” for update

这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。

本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。也就是我们可以在查询数据的时候先用for update把这条数据锁住，然后更改完这条数据再提交。这样别的线程没法更新这条数据，也就保证了不会丢失更新。

乐观锁：乐观锁的实现可以通过在表里面加一个版本号的形式，下面是一个实例。

下单操作包括3步骤：

1.查询出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根据商品信息生成订单

3.修改商品status为2

update t_goods set status=2,version=version+1where id=#{id} andversion=#{version};

个人理解：悲观锁对于大数量多频次访问不太适合，现在已经很少用。乐观锁在选择业务场景的时候也需要注意，并发量高的敏感数据更新操作可能不太合适，但对于库存这样的场景可能合适。