mysql中多版本并发控制（MVCC）与事务性能

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（行锁 + 间隙锁），防止幻读。关键点在于：它锁定的是“当前读”看到的最新可见版本，不是快照里的老版本。

例如，在 REPEATABLE READ 下执行 UPDATE t SET x=1 WHERE id = 5;，即使事务 A 先 SELECT 看到的是旧值，UPDATE 也会去查最新版本（可能被事务 B 刚改过），然后对那行加 X 锁 —— 如果 B 还没提交，A 就会被阻塞。

• SELECT ... FOR UPDATE 和 SELECT ... LO

  

  CK 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 不是银弹。它让读不阻塞写、写不阻塞读，但写之间依然互斥，历史版本堆积成本真实存在，而这些成本往往在业务高峰期才突然暴露。