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存储引擎才有