MySQL官方文档14.3节 — InnoDB多版本控制译文

前言

本篇文章为MySQL官方文档14.3节 — InnoDB多版本控制译文，纯平自己粗浅的英语功底和翻译软件进行翻译，如有问题，欢迎指正。

14.3 InnoDB多版本控制

InnoDB是一个多版本的存储引擎，它保存着有关行修改的旧版本信息，支持事务特性，例如并发和回滚，此信息存储在称为回滚段（oracle的一个类似的数据结构）的数据结构的表空间中，InnoDB使用回滚段中的信息来执行一个事务回滚需要的撤销操作，它还使用这些信息为一个一致性读取操作建立行的早期版本。

实际上，InnoDB为每个存储在数据库中的行都添加了三个字段，一个6字节的DB_TRX_ID字段表示最后一次插入或者更新行的事务操作的事务标识，同样的，一个删除操作被看作为一个内部地更新操作在行的特殊位置被标记为已删除；每个行同样包含一个7字节的DB_ROLL_PTR字段称作为回滚指针，回滚指针指向一个被写入到回滚段中的撤销日志记录，如果行被更新了，撤销日志记录包含在更新该行之前重建该行内容所必需的信息；一个6字节的DB_ROW_ID字段包含一个在有新行插入时单调递增的行ID，如果InnoDB自动生成聚簇索引，索引就会包含行ID的值，否则，DB_ROW_ID列不会出现在任何索引中。

回滚段中的撤销日志分为插入和更新撤销日志，插入撤销日志仅仅在事务回滚时需要，事务一提交就可以丢弃，更新撤销日志也用于一致性读取，但是只有在InnoDB没有分配快照的情况下，才可以丢弃这些快照，在一致性读取中可能需要更新撤销日志中的信息来构建数据库行的早期版本。

定期提交你的事务，包括那些只发生一致性读取操作的事务，否则，InnoDB不能从更新撤销日志中丢弃数据，并且回滚段可能变得太大，填满你的表空间。

回滚段中的撤销日志记录的物理大小通常小于相应的插入或更新的行，您可以使用此信息来计算回滚段所需的空间。

在InnoDB多版本方案中，当您使用SQL语句删除行时，行不会立即从数据库中物理删除，InnoDB只在丢弃为删除而写入的更新撤销日志记录时才物理删除相应的行及其索引记录，这个删除操作被称为清除，并且非常快，通常与删除SQL语句的时间顺序相同。

如果你在表中以相同的速率插入和删除小批量的行，清除线程可能滞后开始，并且由于所有“死”行，表可能变得越来越大，使所有的东西都是磁盘绑定的并且非常慢，在这种情况下，限制新的行操作，并通过调整innodb_max_purge_lag系统变量向清除线程分配更多资源。有关更多信息，请参见第14.14节“InnoDB启动选项和系统变量”。

多版本和二级索引

InnoDB多版本并发控制（MVCC）将二级索引视为与聚簇索引不同，聚簇索引中的记录就地更新，并且他们的隐藏系统列指向可以重建记录的早期版本的撤消日志条目，与聚簇索引记录不同，二级索引记录不包含隐藏的系统列，也不就地更新。

当一个二级索引被更新后，旧的二级索引记录将被标记为删除，新的记录被插入，并且被标记为删除的记录最终会被清除，当二级索引记录被标记为删除或者二级索引页被一个较新的事务更新时，InnoDB查找聚簇索引中的数据库记录，在聚簇索引中，检查记录的DB_TRX_ID，如果记录在读取事务启动后被修改，则从撤消日志中检索正确版本的记录。

如果二级索引记录被标记为删除或者二级索引页被较新的事务更新，则不使用覆盖索引技术，InnoDB不是从索引结构中返回值，而是在聚簇索引中查找记录。

但是，如果启用索引条件下推（ICP）优化，并且仅可以使用索引中的字段来评估WHERE条件的部分内容，MySQL服务器仍将WHERE条件的这一部分向下推送到使用索引进行评估的存储引擎，如果找不到匹配的记录，则避免聚簇索引查找，如果找到匹配的记录，即使在删除标记的记录中，InnoDB也会在聚簇索引中查找记录。