MYSQL日志模块

Undo log

回滚日志 保证事务一致性（ACID之C） 实现数据多版本

日志分为：

• insert 型： 记录insert操作，事务隔离性要求， 对其他事物不可见，故事务提交后可直接删除该undo log，无需后续purge操作
• update 型： 记录delete和update操作，需要提供MVCC机制，不能在事务提交时就删除，提交时放入undo log链表

事务修改数据的前置操作，将更新前的旧值写入undo日志中

针对这种“一个事务读+另一个事务写”的隔离问题，有一种名为“多版本并发控制”（Multi-Version ConcurrencyControl，MVCC）的无锁优化方案，是一种读取优化策略，它的“无锁”是特指读取时不需要加锁，可根据数据版本（行格式存储中三个隐藏列字段：DB_ROW_ID，DB_TRX_ID，DB_ROLL_PTR ）选择能够读取到的数据（非锁定读取），它的实现需要用到undo日志。

说明

DB_ROW_ID：主键

DB_TRX_ID： transaction_id

DB_ROLL_PTR:  回滚指针

日志存储结构

1. 采用段的管理方式， 简称回滚段（rollback segment）,  段个数通过参数： innodb_undo_logs = 16 配置

2. 回滚段构成的文件数量： 通过innodb_undo_tablespaces = 8 配置

日志删除

purge线程： 清理undo页和清理page里面带有Delete_Bit标识的数据行。 在Innodb事务中的Delete操作实际上并不是真正的删除掉数据，而是一种Delete mark操作，在记录上标识Delete_Bit, 而不是真正的删除记录，只是一个标记，真正的删除工作需要后台purge线程完成。

思考

和Undo log相关的疑问：

1. Undo log如何清理？

答案是：依据系统活跃的最小活跃事务ID

2. 为什么InnoDB count（*）这么慢？

答案可能是： undolog的回滚， 此时并发的事务太多，导致每一个事务查询数据的时候，undo log回滚判断耗时超出预期

Redo log

相关概念： log block ，log group， LSN， group commit

实现事务的原子性和持久性（ACID之A&D）， 一种物理格式日志，记录的是对于每个页的物理修改操作，因此其是幂等的（二进制日志binglog，其不是幂等的，不管其设置为哪种格式下），只在Innodb存储引擎才有