MVCC能替代悲观锁吗

简短结论：MVCC 不能完全替代悲观锁，但在大多数读多写少、冲突不激烈的场景下，可以大幅减少甚至避免使用悲观锁。

下面分层说明。

一、MVCC 能解决什么

MVCC（Multi-Version Concurrency Control，多版本并发控制）的核心思想是：

读不阻塞写，写不阻塞读

典型能力：

• 读操作看到的是快照版本，不需要加锁
• 写操作创建新版本，不会互相阻塞读
• 提高并发读性能

✅ 因此，MVCC 天然适合：

• 高并发读
• 读多写少
• 冲突概率低的业务

二、MVCC 不能替代悲观锁的场景

1️⃣ 写–写冲突（核心限制）

MVCC 不能防止两个事务同时修改同一行数据导致逻辑错误。

例子：

事务A：读取余额 = 100
事务B：读取余额 = 100
事务A：余额 - 50 → 写回 50
事务B：余额 - 30 → 写回 70（覆盖A）

MVCC 下：

• 两个事务都能成功提交（取决于隔离级别）
• 但结果是错误的

✅ 解决方式：

• 悲观锁（SELECT ... FOR UPDATE）
• 或乐观锁（版本号 / CAS）

2️⃣ 需要确保“先读后写”原子性的场景

例如：

• 库存扣减
• 余额变更
• 订单状态流转

这些场景要求：

读到的数据，在写的时候必须还是原样

MVCC 本身不保证这一点。

3️⃣ 业务层面的“约束一致性”

MVCC 只解决数据库层面的并发可见性，不解决：

• 业务规则约束
• 跨行、跨表一致性
• 复杂条件判断

例如：

“当 A 表状态为 X，且 B 表数量 > 0 时才允许更新”

这种逻辑通常需要显式加锁。

三、MVCC vs 悲观锁 vs 乐观锁

四、实际应用中的正确姿势

✅ 常见组合方案

1. MVCC + 乐观锁（推荐）

UPDATE account
SET balance = balance - 50, version = version + 1
WHERE id = 1 AND version = 10;

2. MVCC + 悲观锁（强一致）

BEGIN;
SELECT * FROM account WHERE id = 1 FOR UPDATE;
-- 业务逻辑
UPDATE account SET balance = balance - 50 WHERE id = 1;
COMMIT;

3. 纯 MVCC（仅查询）

• 报表
• 历史数据查询

五、总结一句话

MVCC 替代的是“读锁”，不是“写锁”。

• ✅ 可以替代：读时的共享锁
• ❌ 不能替代：写时的互斥保护
• ✅ 最佳实践：MVCC 打底 + 乐观/悲观锁兜底

如果你愿意，可以告诉我你用的是 MySQL / PostgreSQL / Oracle，或者具体业务场景（库存、余额、订单），我可以直接给你更合适的方案。