一句话定义：MVCC（Multi-Version Concurrency Control，多版本并发控制）是数据库同时保留同一行数据的多个历史版本，让"读"和"写"各看各的、互不阻塞的一套机制。
先看没有它会怎样
假设一张订单表，同事正在把某笔订单的金额从 100 改成 200，还没提交。此时你打开报表查这笔订单。
如果数据库只保存一份数据，那只有两条路：要么你读到那个还没确认的 200（脏读），要么你被拦住，等同事提交完才能读。后者就是最朴素的加锁思路——读的时候上读锁，写的时候上写锁，读写互斥。安全，但一到大促、秒杀、报表高峰，读的人把写的人堵住，写的人把读的人堵住，排队能排出天际。
MVCC 的做法：不擦掉，另起一版
MVCC 的思路很像 Git：不覆盖旧内容，而是每次修改产生一个新版本，旧版本继续留着。每一行数据背后都记录着"这版是谁写的、什么时候写的、什么时候被取代的"，形成一条版本链。
当你发起一次查询时，数据库先记下此刻的"时间点"（事务号或快照），然后顺着版本链一版一版往回找，挑出符合这个时间点的那个版本给你。至于你之后别人又提交了多少新版，与你无关——你看到的是你开始那一刻的世界。
于是：读的人在翻旧版本，写的人在追加新版本，两边碰不到同一份数据，自然就不用互相等。
它和"加锁"不是一回事
| 场景 | 纯锁方案 | MVCC |
|---|---|---|
| 读 vs 读 | 不冲突 | 不冲突 |
| 读 vs 写 | 互相阻塞 | 不阻塞 |
| 写 vs 写 | 阻塞 | 仍要处理冲突（行锁或提交时检测） |
| 代价 | 排队等待 | 要存旧版本，还要有清理机制 |
有个常见误解：MVCC 等于"完全不用锁"。并不是。两个事务同时改同一行，还是会打架，该排队排队、该报冲突报冲突。MVCC 主要解决的是读写之间的阻塞。
另外，你能看到多旧的数据，取决于隔离级别（Isolation Level）。不同数据库默认级别不同，语义细节也有差异，以官方文档为准。像"写偏斜"（write skew）这类罕见异常，在纯快照隔离下仍可能发生，需要显式加锁或更高的隔离级别。
对做 AI 的人意味着什么
- 特征平台与训练数据管道：一边有任务在批量回填特征，一边有在线推理在读同一张表。MVCC 让在线读取不被离线写入卡住，这对延迟敏感的服务很关键。
- 标注与审核系统：标注员在改一条样本时，质检员仍能打开它看一眼——他看到的可能是修改前的版本，这是特性不是 bug。
- 别开长事务：旧版本要留到"没人再需要看它"才能回收。一个跑几小时不提交的事务，会让清理机制一直追不上，存储膨胀、查询变慢。批量任务记得分批提交。
一句话记：MVCC 把"排队"换成了"留版本"，代价是要有人负责打扫。