事务
概述
一个事务其实就是一个完整的业务逻辑，是一个最小的工作单元。要么同时成功，要么同时失败，不可再分
假设转账，从A账户向B账户转账10000
A账户的钱减去10000（update语句）
B账户的钱加上10000（update语句）
这就是一个完整的业务逻辑
这两个update语句要求必须同时成功或者同时失败，才能保证钱是正确的。
只有DML(insert、delete、update)语句才会有事务这一说，其他语句和事务无关。
一旦你的操作涉及到增、删、改，那么就一定要考虑安全问题。
事务的实现与操作
主要是通过redo和undo来保证的事务的一致和回滚等操作
redo和undo的区别
- redo和undo的作用都可以视为是一种恢复操作
- redo恢复提交事务修改的页操作
- 而undo回滚行记录到某个特定版本
- 因此两者记录的内容不同
- redo通常是物理日志，记录的是页的物理修改操作。
- undo是逻辑日志，根据每行记录进行记录
redo
- 重做日志是为了实现事务的持久性的，由redo log buffer 和redo log file组成
- InnoDB通过Force Log at Commit机制实现事务的持久性
- 事务的日志写入redo文件进行持久化，等待commit
- 重做日志在InnoDB中，由redo log和undo log组成
- redo log用来保证事务的持久性，是顺序写的
- undo log用来帮助事务回滚及MVCC的功能，随机读写
- InnoDB确保每次日志写入重做日志文件中后要调用fsync来保证数据写入到了磁盘
- fsync的效率取决于磁盘的性能=>决定了事务提交的性能=>数据库的性能
- InnoDB允许事务提交后不立马写入文件，而是一个周期一个周期写入
- 显著提高性能
- 会丢失事务
操作
提交和回滚实现
提交事务：commit;
回滚事务：rollback;（回滚是回滚到上一次的提交点）
事务对应的英文单词是：transaction
mysql中默认事务是自动提交的，就是每执行一条DML语句，则提交一次。
- 这种自动提交实际上是不符合我们的开发习惯，因为一个业务通常是需要多条DL语句共同执行才能完成的，为了保证数据的安全，必须要求同时成功之后再提交，所以不能执行一条就提交一条。
开启事务，mysql就不会默认事务是自动提交了，会关闭自动提交机制
start transaction;//开启事务，并且关闭自动提交机制
insert into dept_bak values(10, 'abc', 'tj');
rollback; //回滚，则上面的insert语句被撤销
start transaction;//开启事务，并且关闭自动提交机制
insert into dept_bak values(10, 'abc', 'tj');
commit;//提交事务
rollback;//回到上一个cimmit后面
事务的分类
- 扁平事务
- 所有操作都处于同一层次，由BEGIN WORK开始，由COMMIT WORK/ROLLBACK WORK结束
- 操作是原子的，要么都执行，要么都回滚
- 不能提交或者回滚事务的某一部分，或分几个步骤提交
- 带保存点的扁平事务
- 支持扁平事务支持的操作
- 允许在事务执行过程中回滚到同一事务中较早的一个状态
- 保存点在事务内部是递增，能回滚到任意正确的保存点
- 保存点是非持久化的
- 链事务
- 提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传给下一个要开始的事务
- 只能恢复到最近一个的保存点
- 嵌套事务
- 层次结构框架，由一个顶层事务（top-level transaction）控制着各个层次的事务
- 由若干事务组成的一棵树，子树既可以是嵌套事务，也可以是扁平事务
- 处在叶节点的事务是扁平事务。但是每个子事务从根到叶节点的距离可以是不同的。
- 根节点的事务称为顶层事务，其他事务称为子事务，事务的前驱称为父事务，事务的下一层称为儿子事务
- 任何子事务都在顶层事务提交后才真正的提交，任意一个事务的回滚会引起它的所有子事务一同回滚
- 分布式事务
- 是一个在分布式环境下运行的扁平事务，因此需要根据数据所在位置访问网络中的不同节点
事务的特性
ACID
原子性（A）
- 说明事务是最小的工作单元，不可再分。
一致性（C）
- 所有事务要求，在同一个事务当中，所有操作必须同时成功，或者同时失败，以保证数据的一致性。
- 一致性也是指符合我们的业务逻辑和结果
隔离性（I）
- A事务和B事务之间具有一定的隔离。相当于多线程并发访问的每个线程。
持久性（D）
- 事务最终结束的一个保障。事务提交，就相当于将没有保存到硬盘上的数据保存到硬盘上！
事务的隔离性
形象的说，A教室和B教室中间有一道墙，这道墙可以很厚，也可以很薄。越厚，隔离级别越高。
事务与事务之间有4个隔离级别
读未提交：read uncommitted（最低隔离级别）《没有提交就能读到》
- 事务A可以读取到事务B未提交的数据。（没有提交就读取到了）
- 这种隔离级别存在的问题就是：脏读现象（Dirty Read），我们称堵到了脏数据。
- 这种隔离级别一般都是理论上的，大多数的数据库隔离级别都是二挡起步。
读已提交：read commited《提交后才能读到》
- 事务A只能读取到事务B提交之后的数据。解决了脏读现象。
- 这种隔离级别存在的问题是：不可重复读取数据。
- 什么是不可重复读取数据呢？在事务开启之后，第一次读到的数据是3条，当前事务还没有结束，可能第二次再读取的时候，读到的数据是4条，3不等于4称为不可重复读取。
- 这种隔离级别是比较真实的数据，每次读到的数据是绝对真实的。
- Oracle数据库默认的隔离级别是：read commited
可重复读：repeatable read《提交后也读不到，读到的都是本事务刚开始的数据》
- 当前事务开始事务的时候，我备份了一份，我读的时备份的数据。不管你外界的事务有没有跟新数据，对我没影响。
- 提交之后也读不到，永远读取的都是刚开启事务时的数据。
- 事务A开启之后，不管多久，每一次在事务A中读取到的数据，都是一致的。即使事务B将数据已经修改，并且提交了，事务A读取到的数据还是没有发生改变，这就是可重复读。
- 存在的问题：可能会出现幻影读。每一次读取到的数据都是幻影，不真实。
- mysql中默认的事务隔离级别。
序列化/串行化：serializable（最高的隔离级别）
- 这是最高隔离级别，效率最低。解决了所有的问题。
- 这种隔离级别表示事务排队，不能并发！
- synchronized，线程同步（事务同步）
- 每次读取到的数据都是最真实的，但是效率是最低的。
验证事务隔离级别
查看隔离级别：select @@tx_isolation
验证：read uncommitted
设置全局隔离级别为“读未提交”：set global transaction isolation level read uncommitted;
解释：打开两个DOS窗口，分别进入数据库，一个DOS窗口开启一个事务。开启事务后，事务B中进行的操作还未提交，在事务A中就能查询到。
个人理解:读未提交,A可以读到B未提交的数据,也就是当A开启事务,B也开启事务后,事务B去修改了数据,但是B并没有commit提交,同时A也没有提交,此时A查询数据,能够读到修改了的数据
此时A没提交,B也没提交就能读到数据
验证：read commited
设置全局隔离级别为“读已提交”：set global transaction isolation level read committed;
解释：事务B进行操作未提交，在事务A查询不到修改后的记录。只有事务B提交了，才能在事务A查询到。（事务B提交，事务A才能查到）
个人理解:读未提交,A可以读到B提交后的数据,也就是当A开启事务,B也开启事务后,事务B去修改了数据,但是B并没有commit提交,同时A也没有提交,此时A查询的数据是没有修改的数据,只有当Bcommit提交事务后,A去读就能读到修改后的数据.
此时A未提交,B提交就能读到数据
验证：repeatable read
设置全局隔离级别为“可重复读”：set global transaction isolation level repeatable read;
解释：事务B操作完提交后，在事务A中查询到的数据，依然是开启事务之前的数据。不论事务B做什么操作，提交几次，只要事务A没提交，查询到的就是以前的。（事务B提交，事务A提交了才能查到）
个人理解:读未提交,A提交后才可以可以读到B提交后的数据,也就是当A开启事务,B也开启事务后,事务B去修改了数据,Bcommit提交了,但是此时A没有提交,这时A查询的数据是没有修改的数据,即使当Bcommit提交事务,A读到的数据依旧是A开启事务之前的数据.只有当A提交事务后,再去查询才能查询到B修改的数据
此时A提交,B提交就能读到数据
验证：serializable
设置全局隔离级别为“序列化”：set global transaction isolation level serializable;
解释：在事务A中进行一些操作，没提交，事务B就去查询结果，会卡在那里。当事务A提交，事务B会立马出现结果。相当于同步了。
个人理解:如果A开启事务后,对user表进行了修改,B去查询user表就会卡主,类似于synchronized锁住了user表,但是当B去查询另外的表就不会卡住.
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
