在 MVCC 中读取和写入元组标头时是否需要锁定？答案

【问题标题】：Is locking required when reading and writing tuple headers in MVCC?在 MVCC 中读取和写入元组标头时是否需要锁定？
【发布时间】：2021-11-02 08:51:58
【问题描述】：

MySQL中引入了几种锁，其中SELECT ... FROM为一致性读，读取数据的快照，不设置锁（除非事务级别为SERIALIZABLE）（https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-set.html）

在 MySQL 中通过向元组添加标头（包括事务版本和指针）和逻辑可见性规则来实现快照（MVCC）

但我们一直强调可见性规则的设计原则，却忽略了对元组Header的读写是两个互斥的动作，只能通过加锁来避免。

那么consistent read without lock这句话怎么理解呢？只是没有广义上的锁吗？ tuple Header 的原子读写是如何设计的？是否有任何性能开销？有没有这方面的资料？

-----补充说明-----

当更新行（元组）时，会保留该行的新版本以及旧副本。每个副本都有一个序列号（事务 id）。

事务ID和副本指针存储在行头中，即创建副本时需要修改行头（更新事务ID和副本指针）。访问行时，需要先访问行头来判断我们要访问的版本（位置）。

修改行头和访问行头应该是两个互斥的动作（否则在并发读写的情况下会读取脏数据），而我想知道的是MySQL执行这部分（行头）阅读和写作的逻辑是如何设计的？是读写锁/自旋锁还是有其他巧妙的方法？

【问题讨论】：

【解决方案1】：

我认为答案是这样的。

更新行时，会保留该行的新版本以及旧副本。每个副本都有一个序列号（事务 id）。在两个事务COMMIT 或ROLLBACK 之后，清理行集——保留幸存的行；其他的都被扔掉了。

该序列号具有将行标记为快照的一部分的效果，该快照是在 BEGIN 时间拍摄的数据集快照的一部分。

序列号等于或早于相关事务的行被事务视为公平游戏读取。请注意，这种“一致读取”不需要锁定。

行的每个副本都有自己的元组标题，具有不同的序列号。这些副本在“历史列表”中链接在一起。对行的更新/删除会将新项目添加到列表中，但保持旧副本不变。（再次指出，旧读取不需要锁定。）

事务隔离“读脏”允许事务遍历历史列表以“查看”最新副本。

性能开销？当然。一切都有性能开销。但是……重要的“表现”是所有行动的总和。有很多复杂性，但最终结果是“更好”的性能。

历史列表的开销很大，但它有助于减少锁定等。

InnoDB 使用“乐观”锁定——即它以假设（希望）它将COMMIT 启动事务。代价是ROLLBACK 效率较低。这似乎是一个合理的权衡。

InnoDB 有很多开销，但它可以在许多基准测试中击败简单得多的 MyISAM 引擎。更快的和 ACID——也可以摆脱MyISAM。这就是甲骨文采取 MySQL 的方向。

【讨论】：

你是对的，当一行（元组）被更新时，新版本的行会被保留，以及旧的副本/副本。每个副本都有一个序列号（事务 id）。事务ID和副本指针存储在行头中，即创建副本时需要修改行头（更新事务ID和副本指针）。访问行时，需要先访问行头来判断我们要访问的版本（位置）
修改行头和访问行头应该是两个互斥的动作（否则在并发读写的情况下会读取脏数据），我想知道的是MySQL执行这个部分（行头）读写的逻辑是怎么设计的？是读写锁/自旋锁还是有其他巧妙的方法？
@Zeng - 搜索 Jeremy Cole -- 他的一些博客提供了更多详细信息。
我搜索了关于他的文章，但没有找到与此主题相关的任何内容。我也在他的博客上发表了评论，但我还没有得到回复。你认识很多这方面的专家。你能帮助艾特的一些人吗？非常感谢。
@Zeng 如果您想了解更多有关 mysql 内部工作原理的详细信息，那么 1) SO 不适合您，因为这是一个编程 QA 站点，您的问题与编程问题无关。您需要 DBA 站点的数据库专业人员。 2) 对于如此详细的问题，您可能需要查看 mysql 的源代码，看看它们是如何实现可重复读取的。