数据库事务的四大特性和事务隔离级别以及MVCC

一、数据库的四大特性（ACID）

1.原子性(Atomicity)：事务包含的操作要么全部成功提交 要么全部失败回滚

2.一致性(Consistency)：事务必须使数据库从一个一致性状态变换到另一个一致性状态， 比如银行里A和B共有5000块 不管两个人之间进行了什么交易 事务结束后两个人共有还是5000

3.隔离性(Isolation)：当多个用户并发访问数据库时 多个并发事务要相互隔离 数据库提供了多种隔离级别

4.持久性(Durability): 当一个事务被提交了 对数据库的改变就是永久的 即使数据库系统遇到了故障也不会丢失提交事务的操作
二、数据库并发引起的问题
1.脏读:在一个事务里读取了另一个没有提交的事务中的数据
2.不可重复读：一个事务内多次查询相同的数据却返回了不同的值 由于在查询间隔 数据被另一个事务修改并提交了
3.幻读：与不可重复读类似都是因为读取了其他的已经提交的事务 幻读针对的是一批数据整体
比如对一组数据进行了从1到2的修改 之后另一个事务插入了一条值为1的数据 就会造成还有一行没有修改的假象
三、事务隔离级别
READ uncommitted(读取没提交)
以上问题都会出现 Oracle不存在(因为Oracle有undo保证一致性 天生读写不阻塞 根本不会出现脏读)
READ COMMITTED(读取已经提交)
可以避免脏读 Oracle默认
Repeatable READ(可重复读取)
确保事务可以多次从一个字段读取相同的值 在这个事务持续期间 禁止其他事务对这个字段进行更新
可以避免脏读和不可重复读 Oracle不存在这个级别 mysql默认
SERIALIZABLE(可串行化)
确保事务可以从一个表中读取相同的行 在事务持续期间不允许其他事务对这个表进行插入删除更新操作
所有并发的问题都可以避免 但是效率十分低下
四、UNDO REDO MVCC
Redo:重做 以恢复操作为目的 重现操作 记录transaction logs 分为online和archived
比如 机器停电了 那么在重启之后需要online redo logs恢复到失败点
比如 磁盘坏了 需要用archived redo logs和online redo logs区恢复数据
UNDO:取消 以撤销操作为目的 返回上一个状态 类似备份(Redo也会记录Undo操作)
比如 我们往一个表中插入一条数据 redo记录这个操作 undo记录这个操作 redo记录上一步undo操作
如果这张表中有索引 表中索引的改变也会作redo和undo
redo和undo都是写在内存中 所以一旦系统崩溃 这些文件将不复存在
数据库很重要的一个东西就是日志 redo log的信息就需要先写到磁盘里，因为它是最原始的操作 能用于场景重现

MVCC(MULTI-VERSION Concurrency Control)多版本并发控制
如果把基于锁的并发控制机制成为悲观机制 MVCC就是乐观机制。乐观与悲观的区别在于
悲观是必须等所有条件完备之后再开始执行，乐观是先碰运气往下做 如果不行再回滚，乐观锁需要回滚 undo就派上用场了。
当我们执行一个事务的时候 oracle会分配一个SCN(SYSTEM COMMIT NUMBER)编号
这个编号是递增的 下个事务的编号肯定比当前事务的大 比如 执行第一个事务分配的编号是10023
在这个事务执行过程中 另一事务10024对编号为10021和10022的数据进行了修改
被替换掉的数据块会被保存在undo上面 当第一个事务执行到被修改过的数据库时 发现10024比10023大
这时undo segment上找比自己SCN号小的数据块进行读 于是发现了10021和10022两个块 这就保证了读一致性。
但是提交的时候需要检查版本冲突 如果失败就需要重做一次

MVCC费时的地方在于版本冲突时 所有mvcc使用于读多于写的场景 因为冲突只会出现在写到的时候， 如果写操作很多就会引起频繁的冲突 是的mvcc花费很多时间在retry。这种情况还不如直接使用锁
所以是否用MVCC还是取决于retry的代价是否大