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（行锁 + 间隙锁），防止幻读。关键点在于：它锁定的是“当前读”看到的最新可见版本，不是快照里的老版本。
例如，在
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 <p>-- 会话 B（修改并提交） START TRANSACTION; UPDATE t SET value = 'new_value' WHERE id = 1; COMMIT;</p><p>-- 回到会话 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 不是银弹。它让读不阻塞写、写不阻塞读，但写之间依然互斥，历史版本堆积成本真实存在，而这些成本往往在业务高峰期才突然暴露。
