冠军资讯
键盘上的咸鱼MySQL 的 MVCC（Multi-Version Concurrency Control，多版本并发控制）机制是实现事务隔离的关键技术。通过 ReadView 与 Undolog 版本链，MVCC 能够让不同的事务在同一时刻读取到不同的数据版本，从而避免脏读、不可重复读等并发问题。本文将深入探讨 MySQL 在 Read Committed（RC，读提交）和 Repeatable Read（RR，可重复读）这两种隔离级别下，如何利用 MVCC 实现数据一致性。
ReadView：一致性读的“快照”
ReadView 是 MySQL MVCC 中至关重要的概念，它本质上是某个事务在执行查询时，系统为它生成的一个“快照”，用于判断哪些版本的数据对该事务可见。ReadView 中主要包含以下几个关键属性：
creator_trx_id: 创建这个 ReadView 的事务 ID。trx_ids: 当前系统中“活跃”的，未提交的事务 ID 列表。low_limit_id: 系统中已分配的最大的事务 ID + 1，也就是下一个要分配的事务 ID。up_limit_id:trx_ids列表中最小的事务 ID。只有小于up_limit_id的事务 ID 修改的数据，才有可能被当前事务读取到。
理解了 ReadView 的作用，就能明白 MySQL 如何控制不同事务对数据的可见性。
Undolog版本链：数据的历史记录
当一条数据被修改时，MySQL 会将旧版本的数据保存在 Undolog 中，并使用 trx_id 将各个版本的数据串联成一个版本链。这样，即使数据被修改，我们仍然可以通过 Undolog 找到历史版本的数据。
为了方便理解，我们假设有一条记录 id = 1, name = '张三'，其初始 trx_id = 10。
- 事务 ID 为 20 的事务将
name修改为'李四'，MySQL 会将name = '张三', trx_id = 10的数据写入 Undolog，并将最新的name = '李四', trx_id = 20数据指向 Undolog 中的旧版本。 - 事务 ID 为 30 的事务又将
name修改为'王五'，MySQL 同样会将name = '李四', trx_id = 20写入 Undolog，并将最新的name = '王五', trx_id = 30数据指向 Undolog 中trx_id = 20的旧版本。
这样就形成了一条版本链：name = '王五', trx_id = 30 -> name = '李四', trx_id = 20 -> name = '张三', trx_id = 10。
RC隔离级别下的MVCC原理
在 RC 隔离级别下，每个事务每次执行查询时，都会创建一个新的 ReadView。这就意味着，如果在同一个事务中，两次查询之间有其他事务提交了修改，那么第二次查询将会读取到最新的数据，从而出现不可重复读的现象。
举例说明：
- 事务 A 开始，
trx_id = 100。 - 事务 A 执行
SELECT * FROM user WHERE id = 1;，创建 ReadView，假设此时trx_ids = [100],low_limit_id = 101,up_limit_id = 100（因为只有事务A）。 此时，如果id = 1的记录的trx_id小于up_limit_id(比如是80)， 则事务 A 可以读取到这个版本的数据。 - 事务 B 开始，
trx_id = 101，修改了id = 1的记录，将name从'张三'改为'李四'，并提交事务。此时id = 1的记录的trx_id变成了101，旧版本张三被写入 Undolog。 - 事务 A 再次执行
SELECT * FROM user WHERE id = 1;，重新创建 ReadView，此时trx_ids = [100],low_limit_id = 102,up_limit_id = 100。 此时，最新的id = 1记录的trx_id是101，大于up_limit_id，所以事务A不能直接读取到最新版本。 此时，MySQL 会沿着 Undolog 版本链，找到trx_id < up_limit_id的版本。因为找不到，最终会读取到trx_id = 80的版本 (最初的版本)。
结论： 在RC隔离级别下，由于每次查询都生成新的ReadView，因此允许读取到其他事务提交的修改，解决了脏读问题，但也带来了不可重复读的问题。
RR隔离级别下的MVCC原理
在 RR 隔离级别下，每个事务第一次执行查询时，会创建一个 ReadView，并且在整个事务执行期间都使用这个 ReadView。这意味着，无论其他事务如何修改数据并提交，当前事务只能读取到在创建 ReadView 时的那一个“快照”。这样就保证了可重复读。
举例说明：
- 事务 A 开始，
trx_id = 200。 - 事务 A 执行
SELECT * FROM user WHERE id = 1;，创建 ReadView，假设此时trx_ids = [200],low_limit_id = 201,up_limit_id = 200。 此时，如果id = 1的记录的trx_id小于up_limit_id(比如是180)， 则事务 A 可以读取到这个版本的数据。 - 事务 B 开始，
trx_id = 201，修改了id = 1的记录，将name从'张三'改为'李四'，并提交事务。此时id = 1的记录的trx_id变成了201，旧版本张三被写入 Undolog。 - 事务 A 再次执行
SELECT * FROM user WHERE id = 1;，仍然使用第一次查询时创建的 ReadView（trx_ids = [200],low_limit_id = 201,up_limit_id = 200）。此时，最新的id = 1记录的trx_id是201，大于up_limit_id，所以事务A不能直接读取到最新版本。 此时，MySQL 会沿着 Undolog 版本链，找到trx_id < up_limit_id的版本。因为找不到，最终会读取到trx_id = 180的版本 (最初的版本)。
注意： 在 RR 隔离级别下，如果事务 A 随后执行了 UPDATE 语句，并且 WHERE 条件正好命中了被事务 B 修改过的记录，那么事务 A 会先去读取事务 B 修改后的最新值，然后再进行修改，这就避免了幻读的发生。这种机制被称为“当前读”，通过加锁来保证数据的一致性。
结论： 在 RR 隔离级别下，由于事务期间只使用一个 ReadView，因此可以避免不可重复读的问题，保证了可重复读。
实战经验与避坑指南
- 合理选择隔离级别： 根据业务需求选择合适的隔离级别。如果对数据一致性要求不高，可以选择 RC 隔离级别，以提高并发性能。如果对数据一致性要求较高，则应选择 RR 隔离级别。
- 关注长事务： 长事务会占用大量的锁资源，并导致 Undolog 膨胀，影响数据库性能。应尽量避免长事务，将大事务拆分成小事务。
- 索引优化： 优化 SQL 语句，避免全表扫描，可以有效减少锁冲突，提高并发性能。可以考虑使用诸如 B+ 树索引，或者全文索引（针对特定的文本搜索场景）等技术。
- 监控数据库状态： 监控数据库的锁等待、慢查询等指标，及时发现并解决性能问题。
- 考虑使用分布式事务： 如果业务涉及多个数据库或服务，可以考虑使用分布式事务，例如 Seata，来保证数据的一致性。结合诸如 Dubbo 等 RPC 框架，可以构建复杂的微服务架构。
理解 MySQL MVCC 的原理，可以帮助我们更好地选择隔离级别、优化 SQL 语句，从而提高数据库的并发性能和数据一致性。
