事务

事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。
原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

事务隔离级别的可能出现的问题

问题

1：脏读。
所谓的脏读，其实就是读到了别的事务回滚前的脏数据。比如事务B执行过程中修改了数据X，在未提交前，事务A读取了X，而事务B却回滚了，这样事务A就形成了脏读。

2.不可重复读
不可重复读字面含义已经很明了了，比如事务A首先读取了一条数据，然后执行逻辑的时候，事务B将这条数据改变了，然后事务A再次读取的时候，发现数据不匹配了，就是所谓的不可重复读了。

如一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两 次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不 可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。

3：幻读
小的时候数手指，第一次数十10个，第二次数是11个，怎么回事？产生幻觉了？
幻读也是这样子，事务A首先根据条件索引得到10条数据，然后事务B改变了数据库一条数据，导致也符合事务A当时的搜索条件，这样事务A再次搜索发现有11条数据了，就产生了幻读。
如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。
总结来说
脏读重点是读取：
读取到为提交的数据，且该数据即将回滚。
不可重复读的重点是修改 :
同样的条件 , 你读取过的数据 , 再次读取出来发现值不一样了 。
幻读的重点在于新增或者删除 ：
同样的条件 , 第 1 次和第 2 次读出来的记录数不一样。

隔离级别

1：Serializable ：最严格的级别，事务串行执行，资源消耗最大；
实现原理是，在读操作时，加表级共享锁，事务结束时释放；写操作时候，加表级独占锁，事务结束时释放。

2：repeatable read ：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
但依然会出现幻读，因为幻读是对整个表而言，突然表中多/少了一行。

实现原理，和读提交数据不同的是，事务读取数据在读操作开始的瞬间就加上行级共享锁，而且在事务结束的时候才释放。分析方法和读提交数据类似，本处不再赘述。但是，由于加锁只是加在行上，所以，仍然可能发生虚读的问题。

3：read committed :大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
read committed比read uncommitted要严格一些，避免了脏读，但是依然会存在不可重复读，因为数据行没有被线程独占，虽然t1，t2同时开启事务，t2先读该行，t1修改该行，t2在自己的事务中再次读该行，就和第一次不一致了。

实现原理是，事务读取数据（读到数据的时候）加行级共享锁，读完释放；事务写数据时候（写操作发生的瞬间）加行级独占锁，事务结束释放。由于事务写操作加上独占锁，因此事务写操作时，读操作也不能进行，因此，不能读到事务的未提交数据，避免了脏读的问题。但是由于，读操作的锁加在读上面，而不是加在事务之上，所以，在同一事务的两次读操作之间可以插入其他事务的写操作，所以可能发生不可重复读的问题。

4：Read Uncommitted ：保证了读取过程中不会读取到非法数据，但是会出现脏读。
read uncommitted就是t1线程可以读取到t2线程中事务未提交的数据。
实现原理是，读数据时候不加锁，写数据时候加行级别的共享锁，提交时释放锁。行级别的共享锁，不会对读产生影响，但是可以防止两个同时的写操作。

在springboot中通过以下注解使用，注解作用于方法

@Transactional(isolation = Isolation.READ_UNCOMMITTED)
@Transactional(isolation = Isolation.READ_COMMITTED)
@Transactional(isolation = Isolation.REPEATABLE_READ)
@Transactional(isolation = Isolation.SERIALIZABLE)

如果不设置，则使用数据库默认的隔离级别
MYSQL: 默认为REPEATABLE_READ级别
SQLSERVER: 默认为READ_COMMITTED

事务传播

注解作用于方法
1.@Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)

2.@Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务

3.@Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务

4.@Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常

5.@Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)

6.@Transactional(propagation=Propagation.SUPPORTS) ：如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务

原理

隔离性由锁得以实现。原子性、一致性、持久性通过数据库的redo和undo来完成。

redo

在InnoDB存储引擎中，事务日志通过重做（redo）日志文件和InnoDB存储引擎的日志缓冲（InnoDB Log Buffer）来实现。
当开始一个事务时，会记录该事务的一个LSN（Log Sequence Number，日志序列号）；
当事务执行时，会往InnoDB存储引擎的日志缓冲里插入事务日志；
当事务提交时，必须将InnoDB存储引擎的日志缓冲写入磁盘（默认的实现，即innodb_flush_log_at_trx_commit=1）。也就是在写数据前，需要先写日志。这种方式称为预写日志方式（Write-Ahead Logging，WAL）。
InnoDB存储引擎通过预写日志的方式来保证事务的完整性。这意味着磁盘上存储的数据页和内存缓冲池中的页是不同步的，对于内存缓冲池中页的修改，先是写入重做日志文件，然后再写入磁盘，因此是一种异步的方式。可以通过命令SHOW ENGINE INNODB STATUS来观察当前磁盘和日志的“差距”。

undo

重做日志记录了事务的行为，可以很好地通过其进行“重做”。但是事务有时还需要撤销，这时就需要undo。undo与redo正好相反，对于数据库进行修改时，数据库不但会产生redo，而且还会产生一定量的undo，即使你执行的事务或语句由于某种原因失败了，或者如果你用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。与redo不同的是，redo存放在重做日志文件中，undo存放在数据库内部的一个特殊段（segment）中，这称为undo段（undo segment），undo段位于共享表空间内。

举例说明：
默认为REQUIRED级别，那么执行以下方法时，如果没有事务，调用lock方法时开启了一个事务。SelectVersion，updateMyLock加入lock事务，方法执行完毕事务结束。
ps：由于查询使用了for update且指定了具体行，将会开启行锁，id=1的元组将被锁定到事务结束，在此期间其他任何事务无法操作该行。

public void lock() {
        Integer version = myLockMapper.SelectVersion(1);        
        MyLock lock = new MyLock().setAge(18).setName("xiaoxiao").setVersion(version).setId(1);     
        myLockMapper.updateMyLock(lock);
    }


@Select("select version from MyLock where id=#{id} for update")
    public Integer SelectVersion(Integer id);
@Update("update MyLock set name=#{name},age=#{age},version=${version}+1 where id=#{id}")
    public void updateMyLock(MyLock mylock);