14.2.2 InnoDB Multi-Versioning InnoDB 多版本:
InnoDB 是一个多版本的存储引擎: 它保留信息关于改变数据的老版本,为了支持事务功能 比如并发和回滚。
这些信息是存储在tablespace 在一个数据结果被称为回滚段(Oracle也有类似的数据结构).
InnoDB 使用的信息在回滚段里执行一个Undo操作需要一个特定的事务回滚。
它也使用信息来创建早期的一致读的版本。
在内部,InnoDB 增加3个字段到每条存储在数据库中的记录。一个 6个字节的DB_TRX_ID 字段
表明事务标识用于上一个事务更新或者插入记录。
此外,一个删除是内部作为一个更新对待 一个特殊的位在记录里是被设置标记为删除。
每行业包含一个7位的字符 DB_ROLL_PTR 字段被称为roll pointer。
roll pointer 指向一个undo log 记录被写入到一个回滚段。
如果记录被更新,undo log 记录包含必要的信息来重建 记录在更新前的内容。
一个 6字节 DB_ROW_ID 字段包含一个row ID 会自动增加作为一个新行被插入。
如果InnoDB 自动产生一个clustered index, index 包含row ID值。
否则 DB_ROW_ID 列不出现在任何索引里。
Undo logs 在回滚段是被划分成Insert和update undo logs.
Insert undo logs 只有在事务回滚时才需要,可以丢弃一旦事务提交。
Update undo logs 是用于一致性读,但是它们被丢弃只有在当前没有事务
InnoDB 已经分配一个快照 在一致性读需要信息在更新undo log 来创建一个早期的数据库记录的版本。
不定期的提交你的事务,包括那些事务只执行一致读。
否则,InnoDB 不能丢弃数据从update undo logs, 回滚段可能会变得很大,填满你的tablespace.
回滚段的物理大小在回滚段是典型的小得相比相应插入或者更改的记录。
你可以使用这个信息来计算你的回滚段需要的东西。
在InnoDB 多版本scheme,一个记录不是立即物理的删除从数据库 当你删除使用一个SQL语句。
InnoDB 只是物理的删除相应的记录和它的索引记录当你丢弃update undo log 记录。
这个操作称为一个purge, 是非常快的,通常花费相同的时间顺序和你的SQL语句 做删除操作一样。
如果 insert 和delete 记录在小批量同样的速率, purge thread 可以启动滞后
表会变得很大很大,因为有很多dead 记录,让磁盘很慢。
在这种情况下,压制新的记录操作,分配更多的资源来purge thread 通过调整innodb_max_purge_lag 系统变量。
多版本和 Secondary Indexes:
InnoDB 多版本并发控制(MVCC) 对待为第2索引 不同于clustered indexes
记录在clustered index 就地更新, 它们隐藏的系统列指向undo log 条目 早期的版本记录可以被重构
不像 clustered index records,secondary index 不包含隐含的系统列也不在原地更新。
当一个 secondary index列被更新,老的secondary index 记录会被标记为删除,
新的记录会被插入, 标记为删除的记录会被清除。
当一个secondary index 记录是标记为删除或者 the secondary index page 是被更新通过一个新的事务,
InnoDB 查找数据库记录在clustered index. 在clustered index,
记录的DB_TRX_ID 是被检查,相应的记录的正确版本是从undo log 检索如果记录被修改在读取,事务开始.
如果一个secondary index record 被标记为删除或者secondary index page 被更新通过一个新的事务,
covering index technique没有被使用。
代替返回值从索引结构,InnoDB 查找记录在 clustered index.
然而, 如果index 条件 pushdown (ICP) optimization被启用,
WHERE 条件的部分可以评估使用唯一的域从Index
MySQL server 仍旧pushes WHERE 条件的这部分到存储引擎 ,被评估为使用index.
如果没有匹配记录被发现, clustered index 查找是被避免。
如果批量的记录被找到, 甚至在标记为删除的记录,InnoDB 查找记录 在clustered index.