MySQL的事务介绍

本周我们继续由Junzhi给我们带来MySQL系列讲座的第三讲，事务的介绍，相关的总结如下：

Slides

1. Junzhi使用的slides。
2. MySQL系列讲座第一讲总结：MySQL DB 引擎的演化和对比 && MySQL Query和Schema Migration的介绍
3. MySQL系列讲座第二讲总结：MySQL存储引擎的深入介绍
4. MySQL系列讲座第三讲总结：MySQL的事务介绍
5. MySQL系列讲座第四讲总结：MySQL锁的介绍 && MySQL主从一致，高可用以及如何实现数据不丢失
6. MySQL系列讲座第五讲总结：MySQL主从一致 && MySQL读写分离实操
7. MySQL系列讲座第六讲总结：Distributed MySQL
8. MySQL系列讲座第七讲总结：Uber是如何选择在Postgres和MySQL之间切换的

Q&A

感谢Richard帮忙整理的笔记总结以及Nancy提供的笔记作为参考。

如何理解隔离性和并发？

1. 两者并不完全一致，Isolation的出现是为了控制并发。保证在多并发的过程中，事务之间互不干扰，或者按照指定的隔离级别读到想要的结果。
2. 【扩展】微软关于SQL Server 隔离性的介绍
3. 【扩展】深入理解MySQL中事务隔离级别的实现原理，很好地介绍了隔离性在MySQL中的实现。
4. 【扩展】一文理解MySQL的事务原则与事务隔离，基本涉及了本次讲座的大多数内容。
5. 【扩展】5分钟带你读懂事务隔离性与隔离级别，这篇文章属于比较基本的例子介绍，可以参考。
6. 【扩展】我们上次关于分布式事务的介绍的总结。

如何理解数据库中的一致性概念

1. DB中的一致性概念，需要保证事务开始和结束时，所有的state是valid的。这里的valid state有多重意义。1) 文件、数据本身是有效的。2) 用户定义的约束是有效的。所以，DB中的consistency通常需要用AID来保证，任何一个前置property没做好，都会让consistency失效
2. 【扩展】如何理解数据库事务中的一致性的概念？知乎关于这个问题的讨论，大家可以借鉴。
3. 【扩展】条分缕析分布式：到底什么是一致性？有涉及到ACID和CAP中一致性的差别。
4. 【扩展】一致性模型，这篇文章总结得蛮好的。

快照读和当前读的区别

1. 在理论中，可重复读 repeatable read隔离级别下，每个事务只会看到事务开始前的历史数据，也就是通过快照读(snapshot read)。这样transaction中如有依赖于原有值的计算操作，就会产生冲突，并且override最新值。但是在实际使用中，InnoDB在快照读的基础上，提供了当前读 current read。如果不考虑背后的实现原理的话，对于使用者来说它总能让使用者读到最新的数据。
2. 【扩展】MySQL-当前读、快照读、MVCC。关于这几个概念的简单介绍。
3. 【扩展】MySQL 高频面试题解析 第02期：当前读和快照读的区别。基本差不多的介绍。
4. 【扩展】Snapshot reading and lock reading – Notes on MySQL 8.0 official documents (III),官方文档关于这个方面的介绍。

InnoDB中MVCC的概念

1. 下图中的最大和最小的id其实是一个全局的id。

1. 【扩展】InnoDB 事务分析-MVCC，从源码级别的分析，很不错的文章。
2. 【扩展】InnoDB Internals – Consistent Reads，同样是源码级别的分析，可以参考。
3. 【扩展】MySQL- 技术专题 -MVCC 机制介绍，不错的一篇介绍MVCC的文章。
4. 【扩展】MySQL-InnoDB-MVCC多版本并发控制，这篇文章写得不错。

关于原slides中下图delete undo log的疑问

1. 这里的第四条关于delete undo log应该是有点笔误(感谢Richard和Junzhi有确认过）。在 InnoDB存储引擎中，undo log 分为：insert undo log和update undo log。insert undo log是指在insert操作中产生的undo log。因为insert操作的记录，只对事物本身可见，对其他事务不可见，故该undo log可以在commit后直接删除，不需要purge操作。update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log 链表，等待purge线程进行最后的删除。所以下图中的delete undo log应该是insert undo log。

Redo log和undo log的介绍

1. 关于何时删除这两个log：在InnoDB中，存在一个purge线程，专门在后台用来删除过期的undo log。因为MVCC存在，所以记录不能在事务提交时立刻删除。若该行记录已经不被任何其他事务饮用，就可以清除。在硬盘中，redo log通常不会被mysql 主动删除，因为redo log承担着recovery的重要职责。大多数情况下，DBA会选择archive过去的redo log。或者在快照备份后，删除之前的redo log（mySQL本身并不支持这个功能，需要应用层通过文件系统层面来实现）
2. 关于undo在recovery不是必须存在。为什么还要undo log？在InnoDB的工程实现层面上，undo log使得回滚操作更加容易。因为每条记录根据rollback potiner将历史版本串在一起。而redo log是全局有序的log，会使得不同事务的操作混杂在一起。undo log在InnoDB中，是支持MVCC的重要组成部分。当然这是因为，InnoDB使用了B+树和聚簇索引的原因，采用了undo log来实现MVCC。同样的，如果是其他的db engine，比如Postgres，并没有使用undo log来支持MVCC，所以也没有使用undo log。
3. 【扩展】官网关于redo log archiving的介绍。
4. 【扩展】彻底搞懂MySQL的redo log，binlog，undo log，关于三者的简单介绍。
5. 【扩展】【图文详解】MySQL系列之redo log、undo log和binlog详解，超级详细的文章，值得一读。
6. 【扩展】说说MySQL中的Redo log Undo log都在干啥，不错的介绍。

再次感谢大家的参与，也希望大家有好的资源能联系我更新这篇文章。谢谢大家。

下周话题安排和往期话题回顾敬请参见《系统设计开荒小分队话题讨论简介》