在构建高可靠性的数据库应用时，我们经常会遇到一个核心挑战：如何让多个用户或进程同时访问和修改数据，而不破坏数据的准确性？这就是数据库管理系统（DBMS）中并发控制的核心所在。如果你正在开发电商系统、金融交易平台或者任何需要处理大量并发请求的应用，理解事务并发问题是至关重要的。
在这篇文章中，我们将深入探讨 DBMS 事务中可能发生的五种主要并发问题。我们不仅会解释它们的理论定义，还会通过实际的代码示例和场景分析，帮助你直观地理解“脏读”、“不可重复读”和“幻读”等问题是如何发生的，以及我们如何通过锁机制、事务隔离级别等技术来有效地解决它们。
什么是并发控制？
并发控制是数据库管理系统的一个关键机制，它确保多个事务可以并发执行而不会相互干扰。如果没有有效的并发控制，数据库的一致性将无法得到保障。试想一下，当两个银行柜员同时读取同一个账户余额并进行修改时，如果没有正确的协调机制，可能会导致数据混乱。
在数据库环境中，当多个事务以不受控制的方式并发执行时，可能会导致以下五种主要的并发问题：
- 临时更新问题（脏读）
- 不可重复读问题
- 丢失更新问题
- 错误汇总问题
- 幻读问题
让我们逐一深入探讨这些问题，并通过实际的代码场景来剖析它们。
1. 临时更新问题（脏读）
脏读是并发控制中最基础但也最危险的问题之一。当一个事务读取了另一个事务尚未提交的中间状态数据时，就会发生脏读。如果后者执行失败并进行了回滚操作，那么前者读取的数据就是“脏”的，即无效的。
#### 实际场景分析
假设我们在处理一个转账场景。事务 A 将用户 A 的 100 元转给用户 B。事务 B 此时正好在读取用户 A 和用户 B 的总资产。
- 时间点 T1：事务 A 开始，从用户 A 扣除 100 元（此时未提交）。
- 时间点 T2：事务 B 读取数据，发现用户 A 的钱少了，但用户 B 的钱还没多（或者反之，取决于隔离级别），计算出总资产异常。
- 时间点 T3：事务 A 因为网络错误回滚，金额恢复原状。
- 结果：事务 B 基于一个从未真实发生过的状态进行了业务逻辑处理，导致数据污染。
#### 代码示例：脏读的产生
为了演示这一点，我们可以打开两个不同的数据库连接窗口（假设使用 MySQL 或 PostgreSQL）。
窗口 1：写事务
-- 开始事务
BEGIN;
-- 更新库存数量为 50（尚未提交）
UPDATE products SET stock = 50 WHERE id = 101;
-- 暂停这里，不要立即 Commit 或 Rollback
-- 此时数据库中该记录的值是 50，但这是未提交状态
窗口 2：读事务
-- 为了看到效果，我们需要将隔离级别设置为 Read Uncommitted
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
BEGIN;
-- 读取数据
SELECT stock FROM products WHERE id = 101;
-- 结果可能显示为 50。这就是“脏读”，因为我们读到了窗口 1 尚未提交的修改。
如果在窗口 1 执行 ROLLBACK;，那么数据库中的实际库存还是原来的值（比如 100），但窗口 2 已经拿到了错误的“50”。在生产环境中，这通常意味着订单会被错误地处理（比如误以为库存不足）。
2. 不可重复读问题
不可重复读是指在同一个事务内，多次读取同一条数据，结果却不一样。这通常是因为在两次读取之间，另一个事务修改了该数据并提交了。
#### 核心区别
注意区分“脏读”和“不可重复读”：脏读读取的是未提交的数据，而不可重复读读取的是已提交的修改。不可重复读关注的是数据内容的修改（Update）。
#### 实际场景分析
场景：财务报表生成。
- 事务 A 开始，读取员工工资为 5000。
- 事务 B 在事务 A 结束前，修改了该员工工资为 6000 并提交。
- 事务 A 再次读取同一员工工资，发现变成了 6000。
这会导致事务 A 内部的逻辑崩溃，因为它原本假设在事务处理期间，工资数据是静态不变的。
#### 代码示例：不可重复读的产生
窗口 1：一致性校验事务
-- 设置默认隔离级别（Read Committed）
BEGIN;
-- 第一次读取
SELECT salary FROM employees WHERE id = 1;
-- 假设结果为 5000
-- 此时暂停...
窗口 2：更新事务
BEGIN;
UPDATE employees SET salary = 6000 WHERE id = 1;
COMMIT; -- 提交修改
窗口 1：继续
-- 第二次读取
SELECT salary FROM employees WHERE id = 1;
-- 结果变为了 6000。如果在同一个事务中，这被称为“不可重复读”。
COMMIT;
解决方案提示：为了解决这个问题，我们需要将隔离级别提升到 REPEATABLE READ（可重复读）。在这个级别下，数据库会保证在事务期间看到的快照是一致的。
3. 丢失更新问题
丢失更新是一个非常经典且棘手的问题。当两个或多个事务选择同一行数据，然后基于最初选定的值更新该行时，就会发生丢失更新问题。这意味着，后提交的事务会覆盖前一个事务所做的更新，导致前一个事务的修改“丢失”了。
#### 实际场景分析
想象一下，我们的电商系统中有一个商品的剩余库存是 10 件。
- 用户 A 买了 1 件。系统读取 10，计算剩余 9，准备写入 9。
- 用户 B 同时也买了 1 件。系统读取 10，计算剩余 9，准备写入 9。
- 如果这两个操作没有严格的并发控制，最终数据库里的库存可能会变成 9，而不是正确的 8。用户 A 的更新被用户 B 的更新覆盖了（或者反之）。
#### 代码示例：丢失更新
窗口 1
-- A 用户购买
BEGIN;
SELECT quantity FROM inventory WHERE product_id = 1; -- 读到 10
-- 假设应用层计算：10 - 1 = 9
UPDATE inventory SET quantity = 9 WHERE product_id = 1;
-- 稍微延迟提交
窗口 2
-- B 用户购买
BEGIN;
SELECT quantity FROM inventory WHERE product_id = 1; -- 读到 10 (还没看到 A 的修改)
-- 应用层计算：10 - 1 = 9
UPDATE inventory SET quantity = 9 WHERE product_id = 1;
COMMIT; -- 先提交，写入 9
窗口 1 继续
COMMIT; -- 后提交，再次写入 9。实际上卖出了2个，库存只扣了1个。
解决方案提示：这是典型的“写冲突”。我们可以通过“乐观锁”（如版本号控制）或“悲观锁”（如 SELECT ... FOR UPDATE）来彻底解决此问题。
4. 错误汇总问题
错误汇总问题通常发生在统计分析场景中。当一个事务正在对某些记录应用聚合函数（如 SUM, AVG, COUNT），而另一个事务正在更新这些记录时，可能会导致计算结果不一致。聚合函数可能会在部分值更新之前读取，而在部分值更新之后读取，从而得出一个既不代表旧状态也不代表新状态的“混合”结果。
#### 实际场景分析
场景：计算所有员工的平均工资。
- 事务 A 开始计算
SELECT AVG(salary) FROM employees;。数据库引擎开始逐行扫描。 - 事务 B 在扫描过程中修改了一部分员工的工资。
- 事务 A 的最终结果是基于部分旧工资和部分新工资计算出来的，这个数字在财务上是没有任何意义的。
#### 代码示例与优化
大多数数据库（如 PostgreSQL, Oracle）通过 MVCC（多版本并发控制）机制，在默认的 Read Committed 级别下也能保证单一查询语句看到的一致性快照。但是，如果你在应用层进行分页汇总，或者数据库配置不当，依然会遇到此问题。
解决方案提示：在进行大规模报表分析时，建议使用快照隔离（Snapshot Isolation）或者在分析期间对相关表加共享锁，防止数据变更干扰计算。
5. 幻读问题
幻读是一个稍微隐蔽一点的问题。它通常发生在事务重新执行一个查询，返回的行集却包含了上次查询中没有的“新”行，或者上次查询中存在的行突然消失了。重点在于：数据行的数量发生了变化，这通常是因为另一个事务插入或删除了满足查询条件的数据。
注意，幻读与不可重复读的区别在于：不可重复读侧重于值的修改，而幻读侧重于行数的增减。
#### 实际场景分析
场景：系统管理员想要删除所有工资大于 20k 的员工记录。
- 事务 A 读取所有工资 > 20k 的员工，发现 10 人，准备删除。
- 事务 B 此时插入了一个新的员工，工资 25k，并提交。
- 事务 A 执行删除操作（可能基于 ID 列表）。结果，那个新插入的工资 25k 的员工依然存在于数据库中（变成了“幻影”）。或者，如果事务 A 重新查询，会莫名其妙发现还有一条记录没删掉。
#### 代码示例：幻读
窗口 1
-- 设置隔离级别为 Repeatable Read（在 MySQL 中 RR 防止幻读，但在某些数据库标准中可能不行）
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- 查找工资 > 20000 的员工
SELECT * FROM employees WHERE salary > 20000;
-- 假设返回了 5 行
窗口 2
BEGIN;
-- 插入一个新高管
INSERT INTO employees (name, salary) VALUES (‘New Boss‘, 25000);
COMMIT;
窗口 1
-- 再次查找
SELECT * FROM employees WHERE salary > 20000;
-- 如果这里返回了 6 行，那就发生了“幻读”。
-- 或者执行 UPDATE 更新这批数据，发现受影响的行数不一致。
COMMIT;
解决方案与最佳实践
面对这些并发问题，我们并不是束手无策。作为开发者，我们可以通过多种技术手段来防止数据不一致。主要的解决方案包括锁定协议、时间戳排序和乐观并发控制。
#### 1. 锁定机制
锁是最直观的解决方式。它的核心思想是：在你操作数据之前，先把这个数据“锁住”，不让别人碰。
- 共享锁：通常用于读取数据。允许其他事务也加共享锁（即可以并发读），但不允许其他事务加排他锁（即不能改）。
- 排他锁：用于写入数据。一旦加上排他锁，其他事务既不能读也不能写。
实战建议：在解决“丢失更新”问题时，我们可以在读取时使用 SELECT ... FOR UPDATE 语句。这会强制获取排他锁，直到事务结束。
BEGIN;
-- 先锁定要修改的行
SELECT stock FROM products WHERE id = 101 FOR UPDATE;
-- 应用逻辑计算新库存...
UPDATE products SET stock = ? WHERE id = 101;
COMMIT;
这样做保证了直到当前事务提交之前，其他事务无法修改这一行，从而确保了更新的原子性。
#### 2. 事务隔离级别
SQL 标准定义了四种隔离级别，从低到高分别是：
- 读未提交：允许脏读。性能最好，但数据最不安全。极少使用。
- 读已提交：禁止脏读，但允许不可重复读。这是大多数数据库（如 PostgreSQL, Oracle）的默认级别。
- 可重复读：禁止脏读和不可重复读。MySQL (InnoDB) 的默认级别。它通过 MVCC 机制保证了同一事务中读取的一致性。
- 可串行化：最高的隔离级别。强制事务串行执行。它禁止脏读、不可重复读和幻读。虽然数据最安全，但因为并发度极低，会导致严重的性能瓶颈，通常只在极端严格的金融场景下使用。
实战建议：不要盲目追求最高的隔离级别。对于一般的 Web 应用，INLINECODE331eec54 已经足够。对于需要保持数据一致性在事务周期的场景（如库存扣减），INLINECODE17a57da7 是更好的选择。
#### 3. 乐观并发控制
乐观锁假设冲突是很少发生的。它不需要在数据库层面加锁，而是通过在表中增加一个 version（版本号）字段来实现。
代码示例：乐观锁
-- 读取数据（带上版本号）
SELECT id, stock, version FROM products WHERE id = 101;
-- 假设读到: stock=10, version=5
-- 在应用层计算新库存 stock=9
-- 更新时，带上版本号条件
UPDATE products
SET stock = 9, version = version + 1
WHERE id = 101 AND version = 5;
在这里，INLINECODEa345948f 语句会检查 INLINECODEcbb68ab9 是否还是 5。如果期间有其他事务修改了数据，version 肯定变了，这次 UPDATE 就会失败（影响行数为 0）。此时，应用层捕获这个错误，提示用户重试或进行数据合并。这种方法在读多写少的高并发场景下（如微博点赞数、文章浏览数）性能极佳，因为它避免了数据库锁的开销。
总结
在 DBMS 的世界里，并没有“银弹”可以解决所有并发问题。
- 脏读 让我们看到了不该看的数据，必须通过
Read Committed以上的级别来避免。 - 不可重复读 破坏了事务内的稳定性，通常通过
Repeatable Read或悲观锁来解决。 - 丢失更新 是业务逻辑的大敌，无论是使用 INLINECODE6faa7340 悲观锁还是 INLINECODE3c0d9ad6 字段乐观锁，都是成熟的应对方案。
- 幻读 是在范围查询时遇到的陷阱，高隔离级别或 Next-Key Lock（如 MySQL InnoDB）可以对付它。
作为一个经验丰富的开发者，我的建议是：首先理解你的业务场景。如果只是简单的查询展示，默认的隔离级别通常足够；如果涉及资金、库存等核心数据，请务必在你的代码中显式地处理并发冲突，无论是选择加锁还是选择乐观重试机制，都需要经过深思熟虑和充分的压力测试。
希望这篇文章能帮助你更好地理解数据库并发控制，并在你的项目中写出更健壮的代码。如果你在实际开发中遇到了复杂的死锁或性能问题，通常意味着你需要审视你的事务边界是否过大，或者是否锁定了不必要的资源。