mvcc通过版本隔离和快照机制避免读写冲突，提升并发性能。1.事务读取时基于“read view”查看历史数据版本，不阻塞写操作；2.写入时创建新版本，不影响旧版本读取；3.使用db_trx_id和db_roll_ptr管理版本可见性；4.后台purge线程清理不再需要的旧版本数据；5.回滚时利用undo log恢复数据状态，不影响其他事务。
MVCC（多版本并发控制）机制通过为每个事务提供一个独立的数据快照，实现了读操作不阻塞写操作，写操作也不阻塞读操作的“非锁定读取”。这意味着，当一个事务在读取数据时，即使另一个事务正在修改相同的数据，读取事务也不会被阻塞，它会看到数据的一个历史版本，从而极大地提升了数据库的并发性能。
解决方案
MVCC的核心在于它不直接修改原始数据，而是为每次修改创建数据的新版本。想象一下，数据库里的每一行数据都像有了一个时间轴，每次更新都会在这个时间轴上留下一个新的“足迹”。当一个事务开始时，它会获得一个“时间戳”或者说一个“视图”，这个视图决定了它能看到哪些数据版本。
具体来说，当一个事务需要读取数据时，它会根据自己的“视图”去查找那些在它开始之前就已经提交（或对它可见）的数据版本。如果某行数据在它开始之后被修改了，它仍然会读取那个旧的版本，因为它只关心它“看到”的那个时间点的数据状态。而当一个事务需要写入数据时，它不会去锁住正在被读取的旧版本，而是创建一个新的数据版本，并将其标记为由当前事务所有。这样，读和写就可以并行不悖地进行，彼此之间互不干扰。这就像你在看一本旧书，而别人在旁边修改这本书的复印件，你们互不影响。
MVCC如何避免读写冲突，提升并发性能？
这其实是MVCC最迷人，也最核心的价值所在。我第一次接触MVCC时，就觉得这简直是数据库并发控制的“圣杯”。传统的锁定机制，无论是行锁还是表锁，都会让读写操作相互等待，在高并发场景下，这简直是性能杀手。而MVCC的出现，彻底改变了这种局面。
它避免读写冲突的关键在于“版本隔离”。当一个事务（比如一个报表查询）开始读取数据时，它会得到一个当前数据库状态的“快照”。这个快照是基于事务开始时的系统版本号或活跃事务列表来确定的。此后，无论其他事务如何修改甚至删除数据，这个读取事务都只会看到它快照里的那个版本。这意味着，读取操作几乎不会被写入操作阻塞，因为它们操作的是不同“时间线”上的数据。
与此同时，写入操作也不会因为有读取操作而等待。写入操作会创建新的数据版本，并更新行记录的元数据（比如，指向新版本的指针或版本号）。旧版本的数据依然存在，供那些持有旧快照的读取事务访问。这种设计极大地减少了锁的竞争，尤其是在读多写少的应用场景中，并发性能的提升是立竿见影的。它让数据库在处理大量并发请求时显得游刃有余，不再是那个动辄“卡壳”的瓶颈。当然，这并不是说完全没有锁，写操作内部，或者为了保证数据一致性，仍然会有锁，但那是行级别的，且持续时间通常很短，与读操作的冲突被巧妙地化解了。
MVCC中的版本管理和可见性规则是怎样的？
要理解MVCC的精髓，就必须深入到它的版本管理和可见性规则。这部分有点像数据库内部的“时间旅行”机制。在许多MVCC实现中，比如InnoDB，每行数据通常会带有一些隐藏的列，这些列用于记录版本信息。最常见的可能是：
- DB_TRX_ID (或类似字段)： 记录了最后一次修改该行的事务ID。
- DB_ROLL_PTR (或类似字段)： 这是一个回滚指针，指向undo log中该行上一个版本的记录。通过这个指针，可以回溯到该行的历史版本。
当一个事务开始时，它会获得一个“Read View”（读取视图）。这个视图包含了当前所有活跃事务的ID列表，以及一个最小和最大的事务ID范围。这个“Read View”就是决定哪些数据版本对当前事务可见的核心规则。
具体可见性判断通常是这样的：
- 对于一行数据的一个版本：
- 如果该版本的DB_TRX_ID小于“Read View”中的最小活跃事务ID，那么这个版本是在当前事务开始之前就已经提交的，它是可见的。
- 如果该版本的DB_TRX_ID大于“Read View”中的最大活跃事务ID，那么这个版本是在当前事务开始之后才创建的，它是不可见的。
- 如果该版本的DB_TRX_ID在最小和最大活跃事务ID之间：
- 如果这个DB_TRX_ID在“Read View”的活跃事务列表中，说明创建这个版本的事务还在进行中（未提交），那么这个版本是不可见的。需要沿着DB_ROLL_PTR回溯到更旧的版本，直到找到一个可见的版本。
- 如果这个DB_TRX_ID不在活跃事务列表中，说明创建这个版本的事务已经提交了，那么这个版本是可见的。
这种机制确保了每个事务都看到了一个逻辑上一致的数据状态，即使底层数据正在被并发修改。这种精妙的设计，使得“非锁定读取”成为可能，也让数据库在并发处理能力上迈上了一个新台阶。
MVCC如何处理事务回滚和旧版本清理？
MVCC虽然带来了巨大的便利，但它也引入了新的管理挑战，尤其是事务回滚和旧版本数据的清理。这就像你不断地制造数据副本，总得有个机制来处理那些不再需要的“旧照片”。
事务回滚： 当一个事务需要回滚时，MVCC的处理相对直接。因为写入操作是创建新版本而不是直接修改旧版本，回滚只需要利用DB_ROLL_PTR指向的undo log信息，将那些未提交的新版本标记为无效，或者通过undo log将数据状态恢复到事务开始前的样子。那些被回滚的未提交的新版本，对于其他事务来说，本来就是不可见的，所以回滚操作不会影响到其他正在运行的事务。这比传统锁定机制的回滚要优雅得多，因为它避免了复杂的锁释放和数据恢复过程。
旧版本清理（Purge）： 这是MVCC实现中一个非常关键且复杂的部分，被称为“垃圾回收”或“Purge”。随着数据不断更新，数据库中会积累大量的旧版本数据。这些旧版本数据不能立即删除，因为可能还有活跃的事务正在使用它们（它们的“Read View”可能需要看到这些旧版本）。
所以，数据库通常会有一个后台线程（例如InnoDB的Purge线程），它会定期扫描那些不再被任何活跃事务引用的旧版本数据，并将其从存储中物理删除。这个过程需要非常小心，因为它必须确保没有正在运行的事务还需要访问这些旧版本。判断一个旧版本是否可以被清理的依据，就是看当前所有活跃事务的“Read View”中，是否都不再需要访问这个版本。如果所有活跃事务的最小可见事务ID都大于这个旧版本的创建事务ID，那么这个旧版本就可以安全地被清理了。
如果旧版本数据积累过多，Purge线程可能会跟不上，这可能导致undo log文件膨胀，甚至影响数据库的性能。因此，一个高效的Purge机制是MVCC数据库健康运行的重要保障。它就像一个默默无闻的清洁工，确保数据库的“时间机器”不会因为历史版本过多而变得臃肿不堪。
