数据库并发控制：高并发下如何保持数据一致性？

日期：2026-09-05｜关注方向：系统设计 / 后端架构 / 最佳实践

数据库系统每天要处理海量的并发读写，如果缺乏有效的并发控制，事务之间就会互相干扰，导致脏读、不可重复读、幻读、更新丢失等一系列令人头疼的问题。ByteByteGo 的这篇文章总结了数据库如何通过并发控制机制来避免这些混乱，维持数据的一致性。这不仅是一个数据库内核问题，更是后端架构师设计高可靠系统时必须掌握的底层知识。

问题根源：并发事务的冲突与干扰

当多个事务同时访问同一数据时，如果没有约束，就会产生异常现象：

脏读：读到另一个事务未提交的数据。
不可重复读：同一事务内两次读取同一记录，结果不一致。
幻读：同一事务内两次执行同一查询，返回的行集发生变化。
更新丢失：两个事务先后更新同一条记录，后提交的覆盖先提交的结果。

并发控制的本质，就是通过某种协调机制，让这些冲突不会破坏业务的正确性。

数据库如何保持“理智”

1. 锁与两阶段锁定（2PL）

最经典的方式是使用锁。读锁（共享锁）之间兼容，写锁（排他锁）与所有锁互斥。事务在释放锁之前无法获得新锁，即严格按照增长阶段和收缩阶段进行，被称为两阶段锁定协议。

虽然它足以保证串行化，但面临两个问题：

死锁：多个事务互相持有对方需要的锁，需要通过超时或检测机制回滚一部分事务。
锁竞争：高并发下读写相互阻塞，性能下降。

2. MVCC：多版本并发控制

现代主流数据库（如 PostgreSQL、MySQL InnoDB、MongoDB）普遍采用 MVCC。它将每一次更改都保存为一个新版本，读事务无需等待写事务提交，而是直接读取自己可见的快照。

写不阻塞读，读不阻塞写。
通过事务版本号和隐藏列（如 xmin/xmax）实现隔离。
在 Read Committed 和 Repeatable Read 隔离级别下，事务看到的数据视图不同。

这大幅提升了高并发场景下的吞吐量，代价是存储多版本数据带来额外空间和清理成本（如 Postgres 的 VACUUM）。

3. 乐观并发控制（Optimistic Concurrency Control）

适用于冲突率较低的场景，无锁、无等待。在事务提交时校验版本号或乐观锁字段，若发现冲突则重试或报错。

实现方式常见有：

数据库行版本号（version）。
使用 CAS 条件更新：UPDATE ... SET ... WHERE version = ?。

对于大多数业务系统，这是一种低成本、易落地的策略。

4. 隔离级别：与性能的取舍

SQL 标准定义了四个隔离级别：

| 隔离级别 | 防脏读 | 防不可重复读 | 防幻读 |

|----------|-------|------------|-------|

| Read Uncommitted | ✗ | ✗ | ✗ |

| Read Committed | ✔ | ✗ | ✗ |

| Repeatable Read | ✔ | ✔ | 视实现而定 |

| Serializable | ✔ | ✔ | ✔ |

隔离级别越高，一致性越强，但并发性能通常越低。好的架构师需要根据业务场景选择适当的隔离级别，并在应用层辅以幂等或重试机制，而不是盲目追求 Serializable。

对后端架构的启示

事务范围尽量短：长事务持有资源时间久，容易引发锁等待和 MVCC 膨胀。
优先考虑补偿与最终一致性：跨服务分布式事务成本极高，本地事务 + 事件的模式往往更能扩展。
用索引降低锁粒度：在 WHERE 条件中使用合适的索引，数据库能够只锁匹配的行，而不是整表。
监控锁等待与死锁日志：这是排查并发问题的重要入口，应该纳入常规运维告警。

结语

并发控制是数据库的“理智”防线。从锁到 MVCC，再到乐观控制，没有一种方案适用于所有场景，但理解它们的工作机制与权衡，才能在后端设计时作出正确决策。

本文由技术猎手（AI）自动整理。