事务
一句话概括：要么全部执行、要么全部不执行
举例：用户下单，你可能还需要记录一些用户信息，但这个过程可能失败了，如果用户成功下单，你就没有这条信息了，这肯定就不行了，此时事务就起到作用了，发生回滚，用户下单失败
作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。
如果所有操作完成，事务则提交，其修改将作用其它数据库进程。如果一个操作失败，则事务将回滚，该事务所有操作的影响都将取消
事务就是被绑定在一起作为一个逻辑工作单元的 SQL 语句分组，如果任何一个语句操作失败那么整个操作就被失败，以后操作就会回滚到操作前状态，或者是上有个节点。为了确保要么执行，要么不执行，就可以使用事务。要将有组语句作 为事务考虑，就需要通过 ACID 测试，即原子性，一致性，隔离性和持久性。
事务分类
1.扁平事务：使用最频繁的事务，要么都成功提交，要么都失败回滚
2.带有扁平点的扁平事务：允许事务回滚到同一个事务中比较早的一个状态
3.链事务：回滚到最近一个保存点，在所有的事务都提交之后才会释放锁，并且通知下一个事务的开始需要上一个事务来通知
4.嵌套事务：树结构，只有当父级事务提交子级事务才会提交，任意一个父级事务的回滚都会导致下面的子级事务回滚
5.分布式事务：操作不同的数据库，使其实现数据的同步，例如将中国银行的钱转到工商银行，这个不同银行的不同数据库，为分布式事务
事务特性
原子性：不可分割性，事务要么全部执行，要么全部不执行
一致性或可串性：事务的执行使数据库从一种正确状态转换成另一种正确状态
隔离性：在事务正确提交之前，不允许把该事务对数据的任何改变提供给任何其它事务
持久性：事务正确提交后，将结果永久保存在数据库中，即使在事务提交后有了其它故障，事务的处理结果也会得到保存
同时多个事务进行会怎么样？或者事务并发问题
多事务的并发进行一般会造成以下几个问题:
- 脏读: A事务读取到了B事务未提交的内容,而B事务后面进行了回滚.
- 不可重复读: 当设置A事务只能读取B事务已经提交的部分,会造成在A事务内的两次查询,结果不一样,因为在此期间B事务进行了提交操作.
- 幻读: A事务读取了一个范围的内容,而同时B事务在此期间插入了一条数据.造成"幻觉".
Mysql中InnoDB支持四种事务隔离级别名称，以及逐级之间的区别
SQL：set global transaction isolation level 隔离级别
设置隔离级别需要重新打开新的session才能生效
1） read uncommited ：读到未提交数据 脏读
这个隔离级别下,其他事务可以看到本事务没有提交的部分修改.因此会造成脏读的问题(读取到了其他事务未提交的部分,而之后该事务进行了回滚).
就是比如上一条修改操作没进行commit提交 而此时去查询的话已经修改了 但这个修改操作还可能回滚
2） read committed：读已提交
其他事务只能读取到本事务已经提交的部分.
这个隔离级别有 不可重复读的问题,在同一个事务内的两次读取,拿到的结果竟然不一样,因为另外一个事务对数据进行了修改.
就比如A事务提交B事务读 但B事务这个过程可能多次读 B事务前两次读的数据相同 但要进行第三次的读的时候数据变了 因为在这之前A事务进行了提交 也可以叫做幻读
3） repeatable read：可重复读
就是将事务隔离开了
可重复读隔离级别解决了上面不可重复读的问题(看名字也知道),但是仍然有一个新问题,就是 幻读,当你读取id> 10 的数据行时,对涉及到的所有行加上了读锁,此时例外一个事务新插入了一条id=11的数据,因为是新插入的,所以不会触发上面的锁的排斥,那么进行本事务进行下一次的查询时会发现有一条id=11的数据,而上次的查询操作并没有获取到,再进行插入就会有主键冲突的问题.
4） serializable ：串行事物
这是最高的隔离级别,可以解决上面提到的所有问题,因为他强制将所以的操作串行执行,这会导致并发性能极速下降,因此也不是很常用.
InnoDB使用哪种隔离级别呢？
默认使用的是可重复读隔离级别
不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。
数据库事务的几种粒度
a. 表锁定：对整个表的锁定。
b. ⾏锁定：只锁定进⾏更改的⾏，例如：insert，update，delete，都隐式采⽤⾏锁定。
c. 数据库锁机制可分为多种粒度的： 数据库，表，⻚⾯，⾏
d. 粒度越⼤，DBMS管理越容易，但是实现并发处理的能⼒就越差，表，⻚⾯，⾏
innodb事务原理之图接MVCC
MVCC全称：Multiversion Concurrency Control多版本并发控制技术
在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空，其实还有一列称为回滚指针，用于事务回滚，不在本文范畴）。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号， 用来和查询每行记录的版本号进行比较
DATA_TRX_ID：这条记录的事务ID 每处理一个事务的时候 ID+1
DATA_ROLL_PTR：存储UNDD LOG的指针，undo log用来记录事务执行命令的记录
DELETE_BIT：用来标记这条记录是否被删除，不是真正的删除，只有commit的时候才会删除
