mvcc通过快照读避免加锁，提升并发性能：普通select不加锁，依据read view和undo log版本链读取可见版本；rc每次查询新建read view，rr仅首次生成并复用；但undo log膨胀会引发io与清理压力。
因为 MVCC 让普通 SELECT 完全不加锁，读操作直接从 Undo Log 版本链中按规则挑一个可见版本，彻底避开与写操作的锁竞争。
快照读不加锁，是性能提升的直接原因
传统锁机制下，SELECT 加共享锁（S 锁），会阻塞后续的更新；而 MVCC 中的“快照读”（即非 FOR UPDATE / LOCK IN SHARE MODE 的普通读）根本不申请任何锁。数据库不是去锁住某行再读，而是根据事务启动时生成的 Read View，沿着 DB_ROLL_PTR 指向的 Undo Log 版本链往前找——只要版本满足可见性规则，就直接返回。
这意味着：
- 成百上千个并发
SELECT可以同时进行，互不等待 - 写事务（
UPDATE/DELETE）只在修改那行时短暂加行级 X 锁，不影响其他事务读旧版本 - 没有锁升级、锁等待、死锁检测等开销
RC 和 RR 隔离级别下 Read View 生成时机不同，影响并发表现
Read View 是决定“能读到哪个版本”的关键，但它生成的时机因隔离级别而异：
-
READ COMMITTED：每次执行SELECT都新建一个Read View，所以同一事务内两次查询可能看到不同结果（已提交的新数据） -
REPEATABLE READ：仅在事务中**第一次**执行快照读时生成Read View，之后复用，保证可重复读
注意：REPEATABLE READ 下虽然读一致性更强，但长期未提交的事务会把 m_ids 列表撑大，导致新事务的 Read View 无法过滤掉更多旧版本，Undo Log 清理延迟，间接拖慢查询——这不是并发能力下降，而是资源堆积引发的副作用。
Undo Log 膨胀是 MVCC 最容易被忽略的隐性成本
MVCC 的代价藏在 Undo Log 里：
- 每条
UPDATE/DELETE都会把旧值写进 Undo Log，并用DB_ROLL_PTR连成链 - 只要还有活跃事务依赖某个旧版本（比如长事务没提交），对应 Undo Log 就不能被 purge
- 大量未清理的 Undo Log 会导致 ibdata 文件膨胀、磁盘 IO 上升、甚至触发
purge thread压力过大而卡顿
所以高并发写入场景下，光看 SELECT 快没用——得盯紧 innodb_max_purge_lag、INFORMATION_SCHEMA.INNODB_METRICS 中的 undo_log_truncated 等指标，否则性能拐点来得突然。
