事务
- 目的
- 保证数据库安全稳定运行的技术
- 四大特性 ACID 原子性 一致性 隔离性 持久性
- 原子性
- 要么都成功,要么都失败
- 实现机制是undo log
- 一致性
- 操作前后,系统稳定,数据移植
- 原子性不代表一致性
- 脏读/不可重复读/幻读
- 解决办法 调整事务隔离级别
- 提交事务后,只有一半操作持久化成功
- 解决办法redo log
- 隔离性
- 每个事物都是独立的,相互不会影响
- 实现机制 多版本并发控制+锁
- 持久性
- 保证食物的执行结果一定能在数据库中同步完成,无论数据库所在硬件是否瘫痪
- 实现机制redo log
- 原子性 持久性 隔离性 实现了一致性
- MVCC多版本并发控制
- 简单来说就是对数据做了多版本处理
- 事务隔离级别中的RC和RR就是MVCC实现的
- RR可重复读级别
- 快照读 select * from xx; #在事务中无论读多少次都和第一次读的结果一样
- 当前读 select * from xx lock in share mode; select * from xx for update insert update delete
- RC读已提交级别
- 仍然有快照读,事务提交成功的数据可以读取得到,单读不到未提交的数据
- 事务隔离级别
- 四个级别,只会用到读已提交和可重复读这两个
- mysql默认为可重复读
- 更新建议使用RC
- 不会加间隙锁(影响并发)
- 索引没触发,不会锁表,只是锁行
- 不可重复和幻读问题,一般不需要管,如果有强一致性要求,加悲观锁/乐观锁
- UNDO
- 作用
- 用于回滚,实现事务的原子性
- 实现多版本并发控制(MVCC)
- 原理
- 在数据操作执行之前,先将牵扯到的数据备份到undo log,然后再进行数据的操作
- Undo Log参与事务的简化过程
1 假设有A、B两个数据,值分别为1,2 2 A.事务开始 3 B.记录A=1到undo log 4 C.修改A=3 (写入缓冲区) 5 D.记录B=2到undo log 6 E.修改B=4 7 F.事务提交
-
- 如果出现回滚操作,系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态
- Undo log必须咸鱼数据持久化到磁盘,如果在D,E之前系统崩溃,undo log是完整的,可以用来回滚事务
- REDO
- Redo Log记录的是新数据的备份
- 作用
- 保证事务持久性
- 原理
- 新数据写入内存缓冲区后,将执行的更新操作写入redo log,再讲数据写入磁盘(一定发生在redo写入之后,单未必立即执行)
- 当系统崩溃时,虽然数据没有写入磁盘,但是Redo Log已经持久化,系统可以根据Redo Log的内容,将所有数据恢复到最新的状态
- 虽然redo log 和写入数据库都是写入磁盘,但是redo log的性能高于写入数据库
- Undo + Redo事务的简化过程
1 假设有A、B两个数据，值分别为1,2 2 A.事务开始 3 B.记录A=1到undo log 4 C.修改A=3 (写入缓冲区) 5 D.记录A=3到redo log (之后的某个时间点写入磁盘) 6 E.记录B=2到undo log 7 F.修改B=4 8 G.记录B=4到redo log 9 J.事务提交
-
- 数据库恢复
- mysql重启后自动进行
- 先REDO,再UNDO
- 进行回复时,
- REDO不区分事务,会重做所有操作(包括未提交的操作和最终回滚的操作)
- 然后再由UNDO来回滚未提交和要执行回滚的事务
- 数据库恢复