MySQL MVCC 用于构建先前快照的高级算法

Question

来自 MySQL manual 关于 InnoDB 多版本：

在内部，InnoDB 为存储在数据库中的每一行添加三个字段。一个 6 字节的 DB_TRX_ID 字段指示插入或更新行的最后一个事务的事务标识符。此外，删除在内部被视为更新，其中行中的特殊位设置为将其标记为已删除。每行还包含一个 7 字节的 DB_ROLL_PTR 字段，称为滚动指针。滚动指针指向写入回滚段的撤消日志记录。如果行已更新，撤消日志记录包含在更新之前重建行内容所需的信息。一个 6 字节的 DB_ROW_ID 字段包含一个行 ID，该行 ID 随着新行的插入而单调增加。如果 InnoDB 自动生成聚集索引，则索引包含行 ID 值。否则，DB_ROW_ID 列不会出现在任何索引中。

但是，我找不到任何有关这些隐藏列（DB_TRX_ID、DB_ROLL_PTR 和 DB_ROW_ID）如何用于构建先前快照的信息，算法是什么？

关于只读事务的手册中的other page 声明如下：

InnoDB 可以避免与为已知为只读的事务设置事务 ID（TRX_ID 字段）相关的开销。只有可能执行写入操作或锁定读取（例如 SELECT ... FOR UPDATE）的事务才需要事务 ID。消除不必要的事务 ID 可以减少每次查询或数据更改语句构造读取视图时所查询的内部数据结构的大小。

考虑到上面的陈述，由于只读事务没有关联TRX_ID，那么应该有与当前事务相关的其他内容与现有行的DB_TRX_ID值进行比较才能能够以确定该特定行是否应包含在构建的快照中。

请描述高级算法以及只读事务的情况，如果它使过程不同。

Answer 1

如果有多个连接修改同一行，则该行的“历史列表”中有该行的多个化身。 TRX_ID 控制可见性：如果化身早于 X，则 Connection 可以“看到”它。否则，它是一个对 this 连接不可见的版本（想想 MVCC 中的 V）。 （注意：transaction_isolation 级别被计入“可见性”。）

我怀疑DB_ROLL_PTR（想想ROLLBACK）仅在请求ROLLBACK（或崩溃调用）时才需要。

我猜只读事务使用TRX_ID，但不会创建新事务，因为它不会创建任何新值来保存历史更改或回滚。

有关更多血腥细节（以及检查我所说内容的有效性），请参阅blogs by JCole。