文章目录
在传统的 MySQL InnoDB 实现中，MVCC 并没有解决"写-写"冲突，它只解决了"读-写"冲突。
如果两个事务同时尝试修改同一行数据，它们依然会互相阻塞。让我们把这个容易产生误解的概念拆开来看，彻底帮你打通任督二脉。
1. 核心纠正：MVCC 的边界
在面试或技术讨论中，一定要明确这个边界：
- 读-读： 不阻塞（天然支持）。
- 读-写： 不阻塞（这是 MVCC 的核心功劳，通过 Undo Log 快照实现）。
- 写-写： 依然阻塞 （MVCC 并不处理这个，靠的是 行锁 / 锁机制）。
所以，如果你觉得"写不应该被阻塞"，那其实是一个误区。 数据库必须保证原子性和一致性，如果两个写操作同时修改同一行而不阻塞，就会发生"覆盖更新（Lost Update）"灾难。
2. 为什么你会产生"写不阻塞"的错觉？
可能是因为你在看文档时，看到了类似"MVCC 提升了写的并发性"这样的话。这其实指的是：写操作不再被读操作阻塞。
场景对比：
- 没有 MVCC（全是锁）： 事务 A 正在读某行，加了读锁（S 锁）。事务 B 想改这行，必须等 A 读完释放锁。这时候写被读阻塞了。
- 有了 MVCC： 事务 A 正在读（快照读）。事务 B 想改这行，直接去修改最新版本并加行锁。B 不需要管 A 在干什么，因为 A 读的是 Undo Log 里的历史版本。这时候写不被读阻塞。
3. "写-写"是如何阻塞的？（当前读）
当你执行 UPDATE、DELETE 或者 INSERT 时，InnoDB 执行的是当前读（Current Read）。
- 取号： 事务尝试修改某行。
- 加锁： 它必须先获取该行的 X 锁（排他锁）。
- 冲突： 如果另一个事务已经持有了这一行的 X 锁，当前的事务就必须进入
lock wait状态。 - MVCC 在哪？ 此时 MVCC 只是在后台默默地为被修改的数据生成 Undo Log 版本，好让那些"只读不改"的事务能看到旧数据。
4. 只有一种情况，写看起来像"不阻塞"
那就是在分布式数据库或者某些特定的存储引擎（如乐观锁机制的 NoSQL）中，采用的是 CAS（Check-And-Set） 或者 写时拷贝（Copy-on-Write）。
但在 MySQL 的 InnoDB 里，写操作必须老老实实排队加锁。
总结：面试怎么说？
如果面试官问："MVCC 是不是让读写都不阻塞了？"
你可以这样优雅地回答：
"准确来说，MVCC 实现了读-写的非阻塞 。它通过版本链让读操作（快照读）不需要等待写操作释放锁。但是，写-写操作之间依然是阻塞的。InnoDB 仍然需要通过行锁（Record Lock）来保证多个事务同时修改同一行数据时的一致性。
所以 MVCC 的本质是**'让读不被写阻塞'**，而不是'让写不被写阻塞'。"
💡 进阶延伸
如果你在研究 Seata 的 AT 模式（你简历里提到的），你会发现它在分布式事务里实现了一套自己的"全局锁"，那其实也是在解决"写-写"冲突，防止脏写。
理解了这一点，你觉得在 RR（可重复读） 隔离级别下，如果一个事务先 SELECT 了一行，然后另一个事务把它删了并提交，第一个事务再去 UPDATE 这行会发生什么？