14.3 InnoDB Multi-Versioning InnoDB 多版本
InnoDB 是一个多版本的存储引擎,它保持信息关于改变的数据老版本的信息,
为了支持事务功能比如并发和回滚。
这些信息是存储在表空间在称为一个rollback segment(Oracle类似的数据结构).
InnoDB 使用信息在回滚段来执行undo 操作在事务回滚时。
它也使用信息来创建记录的早期版本用于一个一致性读
内部的, InnoDB 增加3个字段到每个存储的行在数据库里.
一个6字节的DB_TRX_ID字段表明事务标识用于最好的事务插入或者更新记录。
此外, 一个删除是内部对待为一个update 一个指定的bit在记录内是被设置标记为删除。
每个记录包含一个7字节的DB_ROLL_PTR 字段称为 roll pointer.
回滚指针指向一个undo 日志记录 写到回滚段。
如果记录被更新,undo log 记录包含需要的信息来创建它被更新前记录的内容。
一个6字节的DB_ROW_ID 字段包含一个row ID 单调增加作为新的记录被插入。
如果InnoDB自动生成一个聚合索引,index 包含row ID 值。 否则, DB_ROW_ID 列不出现在任何索引里
Undo logs 在回滚段是被分成insert和update undo logs.
Insert undo logs 是只有在事务回滚时需要,并且可以在事务提交时丢弃。
Update undo logs 是用于一致性读,
但是它们只有在目前没有事务 InnoDB已经分配一个快照在一致性读需要信息在update undo log 来创建一个
定期的提交你的事务,包含那些事务用于一致性读。
否则, InnoDB 不能丢弃数据从update undo logs, rollback segment 会变的很大,填满你的表空间
一个undo log 在回滚段的物理大小是典型的小于相应的插入或者更新的记录。
你可以使用这个信息来计算你的回滚段需要的空间
在InnoDB 多版本策略中,一个记录不是物理删除的从数据库中 当你删除它使用SQL语句。
InnoDB 只是物理的移动相应的记录和它的索引记录 当它丢弃update undo log 记录update undo log 记录。
这个称谓一个purge, 它是非常快的
如果你插入和删除记录以小的匹配以同样的速率, 清除线程可以开始滞后,表的记录会变的越来越大
因为所有的"dead"记录.
多版本和次要索引:
InnoDB 多版本并发控制(MVCC) 对待seconady indexes 不同于clustered indexes.
记录在一个 clustered index 是原地更新, 它们隐含的系统列指向undo log entries 从记录的早期版本被重构。
不像clustered index records,
secondary index records 不包含隐藏的系统列 也不是原地更新
当一个secondary index 列被更新, 老的secondary index records是标记为删除,
新的记录被插入, 标记的记录最终被清理。
当一个 secondary index record 是标记为删除或者 secondary index page 是被一个新的事务更新,
InnoDB 查询数据库记录在 clustered index.
在 clustered index,记录的DB_TRX_ID 是被检查,当前记录的版本是从undo log 检索
如果记录是被修改 在读取事务初始化后
如果一个 secondary index record 是标记为删除或者 secondary index page被一个新的事务更新,
覆盖索引技术就不能使用。