15.3 InnoDB 多版本

InnoDB 是一个多版本存储引擎：它保存已修改数据的旧版本信息，以支持诸如并发和回滚的事务特性。这些信息以一种称作 回滚段 的数据结构（类似于 Oracle 的回滚段）存储在 Undo 表空间中。查看 15.6.3.4 Undo 表空间. 在事务需要回滚时，InnoDB 使用回滚段中的信息执行回滚操作。它也使用这些信息为一致性读构建行的早期版本。查看 15.7.2.3 一致性非锁定读。

在内部，InnoDB 为存储在数据库中的每行增加三个区域（字段）：
一个 6字节 的 DB_TRX_ID 字段,指示插入或更新行的最后一个事务的事务 ID 。同样，删除在内部被视作一种更新，在行中有一个特殊的位（deletion bit），如果被设置，则表示该行被标记为已删除。
一个 7字节 的 DB_ROLL_PTR 字段，叫做 滚动指针 。滚动指针指向一个写入到回滚段中的 Undo Log 记录。如果行被更新，Undo Log 记录包含重建行更新前内容的必要信息。
一个 6字节 的的 DB_ROW_ID 字段包含一个伴随插入新行而单调递增的 Row ID。如果 InnoDB 自动生成了一个聚簇索引，这个索引包含 Row ID 值。否则，DB_ROW_ID 字段不会出现在任何索引中。

回滚段中的 撤销日志（Undo Log） 分为 插入撤销日志（Insert Undo Log） 和 更新撤销日志（Update Undo Log） 。插入撤销日志 仅在事务回滚时需要，事务一旦提交即可丢弃。更新撤销日志 还用于一致性读，InnoDB 在一次一致性读中分配一个需要更新撤销日志中信息来构建数据库行的早期版本的快照给一个事务，仅在当前不存在这样的事务时才能丢弃它。关于撤销日志的额外信息，请参考 15.6.6 Undo Logs.

建议定期提交事务，包含那些仅进行一致性读的事务。否则InnoDB 无法丢弃更新撤销日志中的数据，进而导致回滚段可能增长得非常大填满它所在的 Undo 表空间。有关管理 Undo 表空间的信息，参见 15.6.6 Undo Logs.

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

在InnoDB 多版本模式中，在你使用SQL语句删除一行时，它并不会被立即从数据库中物理删除。InnoDB 仅在丢弃删除操作所写的更新撤销日志时才物理删除相应的行和索引记录。这种删除操作称为清除（purge）,它相当快，通常与执行删除操作的SQL语句处于同一时间级别。

假如你以大约相同的速度小批量地插入和删除行，清除线程可能会开始滞后，表也由于这些“死”行变得越来越大，使得一切受磁盘限制（disk-bound），而且变得越来越慢。此时，阻止新的行操作，通过优化 innodb_max_purge_lag 系统变量分配更多的资源给清除线程。详见 15.8.9 Purge 配置.

多版本和次级（二级）索引

InnoDB 多版本并发控制（MVCC） 处理次级索引与聚簇索引有所不同。在聚簇索引中的记录原位（in-place）更新，它们的隐藏系统列指向可用于重构行记录早期版本的撤销日志条目。不同于聚簇索引，次级索引既不包含隐藏系统列，也不原位更新。

当一个次级索引列更新时，旧的次级索引记录被标记为删除，新的记录插入，旧的被删除标记的记录最终被清除。当次级索引记录被删除标记或次级索引页被更新的事务更新时，InnoDB 在聚簇索引中查找数据库记录。在聚簇索引中，检查记录的 DB_TRX_ID ，如果记录在读事务初始化后被修改，可从撤销日志中返回该记录的正确版本。

如果次级索引记录被标记为删除或次级索引页被更新的事务更新，则无法使用覆盖索引（Covering Index）技术。InnoDB从聚簇索引中查找记录，而不是从索引结构中返回值。

然而，如果启用了 索引条件下推（ICP） 优化，可以仅使用索引中的字段来评估部分 WHERE 条件，MySQL 服务器仍旧会将这部分WHERE条件下推到使用索引评估它的存储引擎层。如果没找到匹配记录，则可以避免查找聚簇索引。如果找到匹配记录（即使它们是被标记为删除的记录），InnoDB 则在聚簇索引中查找这些记录。