【MySQL精通之路】InnoDB(3)-MVCC多版本管理

InnoDB是一个多版本（MVCC）的存储引擎。

它保留有关更改行的旧版本的信息，以支持事务性功能，如并发和回滚。

这些信息存储在称为回滚段的数据结构中的Undo表空间中。

参见“Undo表空间”。

InnoDB使用回滚段（rollback segment.）中的信息来执行事务回滚中所需的撤消操作

它还使用这些信息构建行的早期版本，以实现一致的读取。

参见“无锁的一致读”。

---

在内部，InnoDB向数据库中存储的每一行添加三个字段：

6字节DB_TRX_ID字段

指示插入或更新该行的最后一个事务的事务标识符。此外，删除在内部被视为更新，行中的一个特殊位被设置为将其标记为已删除。

7字节DB_ROLL_PTR字段

回滚指针。滚动指针指向写入回滚段的撤消日志记录。如果该行已更新，则撤消日志记录包含在该行更新之前重新生成该行内容所需的信息。

6字节DB_ROW_ID字段

包含一个行ID，该行ID随着新行的插入而单调增加。如果InnoDB自动生成聚集索引，则该索引包含行ID值。否则，DB_ROW_ID列不会出现在任何索引中。

回滚段中的撤消日志分为插入和更新Undolog。插入Undolog仅在事务回滚中需要，并且可以在事务提交后立即丢弃。

更新Undolog也用于一致读，但只有在不存在InnoDB已为其分配快照的事务之后，才能丢弃这些日志。

在一致读中，快照可能需要更新Undolog中的信息来构建数据库行的早期版本。

有关Undolog的更多信息，请参阅“Undolog”。

【MySQL精通之路】InnoDB(6)-磁盘结构(5)-Undolog-CSDN博客

建议您定期提交事务，包括只发出一致读的事务。

否则，InnoDB无法丢弃更新Undolog中的数据，回滚段可能会过大。

从而填满其所在的Undolog表空间。

有关管理Undolog的信息，请参阅“Undolog表空间”。

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

在InnoDB多版本控制（MVCC）方案中，当您使用SQL语句删除一行时，它不会立即从数据库中物理删除。

当InnoDB丢弃为删除而写的更新Undolog记录时，它只物理地删除相应的行及其索引记录。此删除操作被称为清除，而且速度非常快，通常与执行删除的SQL语句所花费的时间顺序相同。

如果在表中以大致相同的速率小批量插入和删除行，则清除线程可能会开始滞后，并且由于所有“死行”（dead rows），表可能会变得越来越大，从而使所有内容都绑定到磁盘，并且速度非常慢。

在这种情况下，通过调整innodb_max_purge_lag系统变量来限制新行操作，并为清除线程分配更多资源。

有关更多信息，请参阅“清除配置”。

2.多版本控制和辅助索引

InnoDB多版本并发控制（MVCC）对待二级索引的方式不同于聚集索引。

聚集索引中的记录会立即更新，其隐藏的系统列指向撤消日志项，可以从中重建早期版本的记录

与聚集索引记录不同，辅助索引记录不包含隐藏的系统列，也不会立即更新。

更新辅助索引列时，会对旧的辅助索引记录进行删除标记，插入新记录，并最终清除带有删除标记的记录。

当二级索引记录被删除标记或二级索引页面被更新的事务更新时，InnoDB会在聚集索引中查找数据库记录。

在聚集索引中，检查记录的DB_TRX_ID，如果在启动读取事务后修改了记录，则从撤消日志中检索记录的正确版本。

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

但是，如果启用了索引条件下推（ICP）优化，并且只能使用索引中的字段来评估WHERE条件的部分，MySQL服务器仍然会将WHERE条件的这一部分下推到使用索引进行评估的存储引擎。

如果找不到匹配的记录，将避免进行聚集索引查找。

如果找到匹配的记录，即使在已删除标记的记录中，InnoDB也会在聚集索引中查找该记录。