redo日志

• 防止内存丢失

简单日志类型

复杂日志类型

redo日志组

• 保证原子性 ，就放到一个日志组里面，根据结尾标识，恢复前面所有的日志

MTR

• 对底层页面进行一次原子访问的过程就叫做MTR,类似一个日志组，每个MTR里面有多条redoLog

  

redo Log Block

• redo日志缓冲区 log buffer

• 开始事务->执行sql->写redo log->组成mtr->写入block->写到logbuffer

redo日志刷盘和日志文件组

 1. logbuffer空间不足50%
 2. 事务提交的时候
 3. 后台有个线程，每秒一次的频率进行刷盘
 4. 关闭服务器的时候
 5. 做checkpoint
 

redo日志文件格式

• 是通过内存里面的512b进行划分的

lsn （全局变量之一）

• 记录当前总共已经写入的redo日志量
• 初始值是8704

redo日志刷新到磁盘长度

undo日志

什么事undo log

• 事务要求保证原子性 ，需要进行异常回滚，需要记录undo日志
• select 不需要进行记录

事务id

insert操作对应的undo日志

delete操作对应undo日志

update操作对应的undo日志

事务

ACID

• 一致性
• 隔离性
• 原子性
• 持久性

事务并发执行时数据一致性的问题

• 四种隔离级别
  • 读未提交 脏读
  • 读已提交 不可重复读 同一事物内 两次查询结果不同
  • 可重复度 幻读
  • 串行化

MVCC（多版本并发控制）

• 利用版本链和ReadView（类似快照），来控制并发事务访问相同记录

版本链

• 每次记录更新之后，都会把旧值放到一条undo日志中，随着更新次数的增加，所有的版本都会被 roll_point属性连接成一条链表，这个就是版本链

  

ReadView包含的内容

• 通过ReadView来判断记录的某个版本是否可见
• 读已提交和可重复读的区别：它们生成readView的时机不同
  • 读已提交，在一个事务中每次读取事务前都生成一个ReadView（每次的活跃事务都不一样）
  • 可重复读，在一个事务中，只在第一次读取数据的时候生成一个ReadView，后面每次的查询都是复用第一个ReadView（整个事务中，他的活跃事务都相同，不管别的活跃事务是否已经提交，都不会去采用，而是根据版本链向下查）

版本链的生成规则

RC的readview里面活跃事务是20，所以会向下去取trx_id为10，RR的活跃事务版本是20、10，所以向下查到trx_id为2的