InnoDB是一个多版本存储引擎：它保留有关已更改行的旧版本的信息，以支持事务功能（如并发和回滚）。此信息存储在称为回滚段（在Oracle中的类似数据结构之后）的数据结构中的表空间中。
InnoDB使用回滚段中的信息执行事务回滚中所需的撤消操作。它还使用信息来构建一个行的早期版本以实现一致性读取。在内部，InnoDB为数据库中存储的每一行添加三个字段。
6字节的DB_TRX_ID字段指示插入或更新行的最后一个事务的事务标识符。此外，删除在内部被视为更新，其中行中的特殊位被设置为将其标记为已删除。
每行还包含一个7字节的DB_ROLL_PTR字段，称为滚动指针。滚动指针指向写入回滚段的撤销日志记录。如果行已更新，则撤消日志记录包含在更新行之前重建行的内容所需的信息。 6字节的DB_ROW_ID字段包含随着插入新行而单调增加的行ID。如果InnoDB自动生成聚簇索引，则索引包含行ID值。否则，DB_ROW_ID列不会出现在任何索引中。撤销日志在回滚段中分为插入和更新撤销日志。插入撤销日志仅在事务回滚中是需要的，并且可以在事务提交时立即丢弃。更新撤消日志也用于一致性读取，但是它们可以在没有事务存在时被丢弃，InnoDB已为其分配了一个快照，该一致性读取可能需要更新中的信息undo日志以构建早期版本的数据库行。定期提交您的事务，包括只发出一致性读取的事务。否则，InnoDB不能从更新撤销日志中丢弃数据，并且回滚段可能增长过大，填满您的表空间。回滚段中的撤销日志记录的物理大小通常小于对应的插入或更新的行。您可以使用此信息计算回滚段所需的空间。在InnoDB多版本方案中，在使用SQL语句删除行时，不会立即从数据库中物理删除该行。 InnoDB仅在物理删除对应的行及其索引记录时，丢弃为删除写入的更新undo日志记录。这个删除操作称为清除，它非常快，通常采取与执行删除的SQL语句相同的时间顺序。如果在表中以相同的速率以小批量插入和删除行，则清除线程可能开始落后，并且表可以变得越来越大，因为所有“死”行，使得一切磁盘绑定，非常慢。在这种情况下，节流新行操作，并通过调整innodb_max_purge_lag系统变量来为清除线程分配更多资源。有关详细信息，请参见第15.14节“InnoDB启动选项和系统变量”。
多版本和二级索引
InnoDB多版本并发控制（MVCC）不同于聚簇索引处理辅助索引。聚集索引中的记录将原位更新，其隐藏的系统列指向可以重建早期版本的记录的日志条目。与聚集索引记录不同，辅助索引记录不包含隐藏的系统列，也不会原位更新。更新辅助索引列时，将删除旧的辅助索引记录，插入新记录，最终清除已删除标记的记录。当辅助索引记录被删除标记或辅助索引页由较新的事务更新时，InnoDB在聚簇索引中查找数据库记录。在聚簇索引中，将检查记录的DB_TRX_ID，如果在读事务启动后修改了记录，则从撤销日志中检索正确的记录版本。如果二级索引记录被标记为删除或二级索引页被更新的事务更新，则不使用覆盖索引技术。 InnoDB不是从索引结构中返回值，而是查找聚集索引中的记录。但是，如果启用索引条件下推（ICP）优化，并且可以仅使用索引中的字段来评估WHERE条件的部分，则MySQL服务器仍将WHERE条件的这部分下推到存储引擎使用索引。如果没有找到匹配的记录，则避免聚集索引查找。如果找到匹配的记录，即使在删除标记的记录中，InnoDB也会在聚集索引中查找记录。
