MySQL中MVCC的实现原理
引言
在数据库事务管理中，undo log起着至关重要的作用。它不仅用于在事务发生错误时实现数据的回滚，确保数据的一致性和完整性，还支撑了多版本并发控制（MVCC）机制下的非锁定读操作。通过保存数据更新前的原始版本，undo log为事务的回滚和快照读提供了必要的数据支持。MVCC的实现依赖于数据行中的隐藏字段和活跃事务数组，通过判断事务的提交状态来确定数据的可见性，进而实现不同隔离级别下的数据读取策略。本文将围绕undo log的作用、MVCC的核心机制及其在隔离级别中的应用进行深入探讨。
undo log的作用
- 事务发生错误时回滚rollback，数据更新之前，会把原始数据保存在undo log中，保证事务出错回滚或者我们手动回滚的时候，能够在undo log中找到最初的数据。
- 提供了MVCC的非锁定读（快照读），依赖undo log实现。
MVCC的实现有以下几个重要因素
- 数据行的两个隐藏字段，db_trx_id（事务id）、db_roll_ptr（回滚指针），回滚指针指向拷贝的undo log副本记录。
- 活跃事务数组，针对可重复读隔离级别，活跃事务列表是在事务启动瞬间，当前正在“活跃”的所有事务 ID，也即事务启动瞬间未提交的事务。
- 活跃事务数组最小值为低水位，活跃事务数组最大值加1为高水位。
例如：活跃事务数组：【20，23，31】，低水位：20，高水位：32。
如何根据这些因素判断数据值？
已数据行的db_trx_id为起始点，延着回滚链取出db_trx_id按照下面规则判断是否可见，直到找到可见的数据才停止查找：
- db_trx_id <= 低水位，表示当前事务早已经提交，可见。
- db_trx_id >= 高水位，表示当前事务还未提交，不可见。
- db_trx_id能在活跃事务列表找到，表示当前事务还未提交，不可见。
- db_trx_id不能在活跃事务列表找到，表示当前事务已提交，可见。
可重复读和已提交读区别？
可重复读是在事务启动时创建视图，已提交读是在每条查询SQL执行时创建视图。视图主要是用于记录活跃（未提交）的事务ID列表。
感谢您的阅读！如果文章中有任何问题或不足之处，欢迎及时指出，您的反馈将帮助我不断改进与完善。期待与您共同探讨技术，共同进步！