MySQL的MVCC通过隐藏字段DB_TRX_ID和DB_ROLL_PTR配合Read View实现：事务启动时生成Read View，根据DB_TRX_ID与min_trx_id、max_trx_id及活跃事务列表比较判断版本可见性；RR级别复用首次Read View，RC级别每次SELECT新建。
MySQL 的 MVCC 是怎么靠隐藏字段和 Read View 实现的
MVCC 不是 MySQL 自己发明的“黑科技”，而是 InnoDB 在 REPEATABLE READ 和 READ COMMITTED 隔离级别下，用一套轻量机制避免读写冲突。核心依赖两个隐藏字段：DB_TRX_ID（记录最后一次修改该行的事务 ID）和 DB_ROLL_PTR（指向 undo log 中的历史版本链）。每次事务开始时，InnoDB 会生成一个 Read View，里面存着当前活跃事务 ID 列表、最小未分配事务 ID（min_trx_id）、最大已提交事务 ID（max_trx_id）等信息。
判断某条记录对当前事务是否可见，就靠这个 Read View 和每行的 DB_TRX_ID 比较：如果该行的 DB_TRX_ID 小于 min_trx_id，说明修改早于本事务快照，可见；如果大于等于 max_trx_id，说明是未来事务改的，不可见；如果落在中间，则查活跃事务列表，若在其中，说明还没提交，不可见。
-
REPEATABLE READ下，Read View在事务第一次 SELECT 时创建，之后复用 —— 所以能保证“可重复读” -
READ COMMITTED下，每次 SELECT 都新建Read View—— 所以能看到其他事务刚提交的数据 - INSERT 不需要判断可见性，直接写最新版本；DELETE 是逻辑删除（打标记），UPDATE 是先删后插（新行 + 旧行回滚指针）
为什么长事务会让 undo log 膨胀、MVCC 变慢
只要有一个事务没结束，它的 Read View 就一直有效，InnoDB 就不能清理比它更老的 undo log 版本。结果就是 undo tablespace 占用持续增长，SELECT 查询时要遍历更长的版本链，CPU 和 buffer pool 压力都会上升。
典型现象包括：SHOW ENGINE INNODB STATUS 里看到 HISTORY LIST LENGTH 持续 > 10000；information_schema.INNODB_TRX 中有运行数小时的事务；查询响应时间波动变大，尤其涉及大范围扫描时。
- 用
SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_MYSQL_THREAD_ID FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED;快速定位长事务 - 避免在事务里做 HTTP 调用、文件读写、sleep() 等阻塞操作
- 业务上拆分大事务：比如批量更新 10 万行，改成每 1000 行 commit 一次，而不是包在一个事务里
UPDATE / DELETE 语句在 MVCC 下如何加锁
MVCC 解决的是“一致性非锁定读”，但写操作（UPDATE、DELETE）仍需加锁。InnoDB 默认用 next-key lock（行锁 + 间隙锁），防止幻读。关键点在于：它锁定的是“当前读”看到的最新可见版本，不是快照里的老版本。
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
例如，在 REPEATABLE READ 下执行 UPDATE t SET x=1 WHERE id = 5;，即使事务 A 先 SELECT 看到的是旧值，UPDATE 也会去查最新版本（可能被事务 B 刚改过），然后对那行加 X 锁 —— 如果 B 还没提交，A 就会被阻塞。
-
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE都是当前读，触发加锁，也受 MVCC 可见性规则影响（先确定读哪版，再锁那版） -
INSERT INTO ... SELECT、CREATE TABLE ... SELECT这类语句内部会做隐式当前读，也可能锁住大量记录 - 唯一索引等值查询（如
WHERE id = ?）只锁匹配行；范围查询（如WHERE id > 100）会锁住间隙，甚至整个区间
如何验证 MVCC 是否生效、有没有意外退化成锁表
最直接的方式是开两个会话，模拟并发读写，观察行为是否符合预期。不要只看执行计划或状态变量，要实测可见性和阻塞关系。
-- 会话 A（开启事务，不提交） START TRANSACTION; SELECT * FROM t WHERE id = 1; -- 返回 old_value-- 会话 B（修改并提交） START TRANSACTION; UPDATE t SET value = 'new_value' WHERE id = 1; COMMIT;
-- 回到会话 A SELECT * FROM t WHERE id = 1; -- 仍返回 old_value（MVCC 生效） UPDATE t SET value = 'from_A' WHERE id = 1; -- 会阻塞，直到 B 提交后才继续（因为要锁最新行）
容易被忽略的退化场景：
- 查询没走索引 → 降级为全表扫描 + 行锁，极大增加锁冲突概率
- 使用了
SELECT ... FOR UPDATE但 WHERE 条件不精确 → 锁住远超预期的行数 - 隔离级别设为
SERIALIZABLE→ 所有普通 SELECT 都自动转成LOCK IN SHARE MODE，彻底失去 MVCC 优势
MVCC 不是银弹。它让读不阻塞写、写不阻塞读，但写之间依然互斥，历史版本堆积成本真实存在，而这些成本往往在业务高峰期才突然暴露。
