MySQL在处理并发更新问题时，核心策略在于通过锁机制（包括行锁和表锁）、事务隔离级别以及多版本并发控制（MVCC）的协同作用，来确保数据的一致性和完整性。简单来说，它就像一个交通指挥官，通过各种规则和信号灯，协调多辆车（并发事务）在同一条路上（数据）行驶，避免碰撞（数据冲突），确保大家都能安全、有序地到达目的地。

解决方案

当我们面对MySQL中的并发更新，最直接且有效的解决方案通常围绕着以下几个关键点展开：

1. 悲观锁（Pessimistic Locking）：这是最直观的解决方式，它假设并发冲突一定会发生，因此在操作数据之前就先将其锁定，阻止其他事务访问。在MySQL的InnoDB存储引擎中，我们最常用的是

   SELECT ... FOR UPDATE

   。当你执行这条语句时，MySQL会为选定的行加上一个排他锁（X锁），直到当前事务提交或回滚，其他事务都无法对这些行进行修改，甚至在某些隔离级别下也无法读取（取决于锁类型和隔离级别）。这种方式能最大程度地保证数据的一致性，但代价是并发性能会受到影响，因为资源被长时间占用。比如，一个用户在更新库存时，其他用户就得等着，这在某些高并发场景下是不可接受的。

2. 乐观锁（Optimistic Locking）：与悲观锁相反，乐观锁假设冲突发生的概率很低。它不直接锁定资源，而是在更新数据时去检查数据自上次读取后是否被其他事务修改过。最常见的实现方式是为表添加一个版本号（

   version

   字段）或时间戳（

   updated_at

   字段）。

   • 流程：
     1. 读取数据时，同时读取其版本号（

        version

        ）。

     2. 进行业务逻辑处理。
     3. 更新数据时，将版本号加1，并带上之前读取的版本号作为

        WHERE

        条件：

        UPDATE your_table SET column1 = 'new_value', version = version + 1 WHERE id = ? AND version = ?;
     4. 如果

        UPDATE

        语句影响的行数为0，说明在你的事务处理期间，数据已经被其他事务更新了（版本号不匹配），此时你需要根据业务需求选择重试、报错或合并冲突。 乐观锁的优势在于提高了并发性，因为读取操作不会加锁。但缺点是需要应用程序层面处理冲突和重试逻辑，并且在冲突频繁的场景下，可能会导致大量的重试操作，反而降低效率。

3. 事务隔离级别（Transaction Isolation Levels）：MySQL的InnoDB引擎提供了四种事务隔离级别，它们在并发控制中扮演着重要角色：

   • READ UNCOMMITTED

     ：读到未提交数据（脏读），极少使用。

   • READ COMMITTED

     ：读到已提交数据，避免脏读，但可能出现不可重复读。

   • REPEATABLE READ

     ：MySQL InnoDB的默认级别，避免脏读和不可重复读，但可能出现幻读（通过间隙锁解决）。它通过MVCC机制，让事务在启动时创建一个“快照”，后续读取都基于这个快照。

   • SERIALIZABLE

     ：最高隔离级别，所有事务串行执行，避免所有并发问题，但并发性能最低，相当于强制加表锁。 在大多数情况下，

     REPEATABLE READ

     配合InnoDB的MVCC机制，能够很好地平衡数据一致性和并发性能。

4. 多版本并发控制（MVCC）：这是InnoDB的一个核心特性，尤其在

   READ COMMITTED

   和

   REPEATABLE READ

   隔离级别下发挥作用。它允许读操作在不阻塞写操作，写操作在不阻塞读操作的情况下进行。当一个事务修改数据时，InnoDB不会直接覆盖旧数据，而是通过undo日志记录旧版本，并为修改后的数据生成一个新版本。这样，读事务可以根据其启动时的“快照”读取旧版本数据，而写事务则处理新版本。MVCC极大地提升了并发读写的性能，避免了读写冲突，让“读不加锁，写不阻塞读”成为可能。

InnoDB的MVCC机制在并发更新中扮演什么角色？

要我说，MVCC（Multi-Version Concurrency Control，多版本并发控制）简直是InnoDB并发处理的“魔法棒”，尤其是在并发更新的场景下，它的存在让我们的数据库能更高效地工作。

它最核心的作用是实现了读写分离，或者说，让读操作在大多数情况下不再需要等待写操作释放锁。这怎么做到的呢？简单来说，当一个事务需要读取数据时，它并不会去读取当前最新、可能正在被其他事务修改中的数据，而是根据自身的事务隔离级别（比如

REPEATABLE READ

），去读取一个“历史版本”的数据快照。这个快照是事务启动时的数据状态，或者是在

READ COMMITTED

级别下，每次读取时已提交的最新状态。

具体机制是这样的：InnoDB为每一行记录都保存了两个隐藏列：

DB_TRX_ID

和

DB_ROLL_PTR

。

• DB_TRX_ID

  ：记录了最新修改该行的事务ID。

• DB_ROLL_PTR

  ：指向

  undo log

  中该行上一个版本的记录。 通过这些信息，以及一个

  Read View

  （读视图），InnoDB就能构建出事务启动时的数据“快照”。当一个事务读取数据时，它会检查行的

  DB_TRX_ID

  ，如果该事务ID在当前事务的

  Read View

  中是不可见的（比如是比当前事务晚启动的事务，或者是一个未提交的活跃事务），那么它就会沿着

  DB_ROLL_PTR

  链去

  undo log

  中寻找更早的版本，直到找到一个对当前事务可见的版本。

在并发更新中，MVCC的价值体现在：

• 提升并发性：读操作不再需要等待写操作释放行锁，大大减少了锁竞争，提高了数据库的吞吐量。一个用户在修改一条记录时，另一个用户依然可以读取到修改前的版本，而不会被阻塞。
• 避免脏读和不可重复读：在

  READ COMMITTED

  和

  REPEATABLE READ

  隔离级别下，MVCC通过维护多版本数据，确保事务读取到的都是已提交的数据，并且在

  REPEATABLE READ

  级别下，同一个事务内多次读取同一行数据，结果总是一致的。

• 简化应用逻辑：应用程序无需过多关注底层的锁细节，大部分的读操作可以自然地获得一致性视图。

当然，MVCC并非万能。它主要解决的是读写冲突，对于写写冲突，我们依然需要依赖悲观锁（如

SELECT ... FOR UPDATE

）或乐观锁机制来处理。在我看来，MVCC是InnoDB能够成为高性能OLTP（在线事务处理）数据库的关键基石之一，没有它，我们的并发更新问题会变得复杂得多。

如何选择悲观锁与乐观锁，以及它们各自的适用场景？

选择悲观锁还是乐观锁，这其实是个“哲学问题”，更是个实际的业务决策。没有绝对的优劣，只有适不适合你的场景。这有点像开车，高速公路你肯定想开快点，但小巷子里你就得小心翼翼。

悲观锁（Pessimistic Locking）

• 特点：它是一种“先发制人”的策略。在操作数据前就假设会有冲突，所以先把它锁起来，不让别人动。

  SELECT ... FOR UPDATE

  就是典型的悲观锁。

• 优点：
  • 数据一致性极高：一旦加锁，其他事务就无法修改，确保了操作期间的数据绝对安全。
  • 逻辑相对简单：应用程序不需要处理复杂的冲突检测和重试逻辑，因为冲突在数据库层面就被阻止了。
• 缺点：
  • 并发性能低：锁定了资源，其他事务只能等待，在高并发场景下可能成为瓶颈。
  • 可能发生死锁：如果多个事务以不同的顺序获取锁，很容易陷入死锁状态。
  • 事务粒度大：锁通常持续到事务结束，可能导致长事务，占用资源时间长。
• 适用场景：
  • 高冲突、数据一致性要求极高的场景：例如，库存扣减、银行转账、秒杀系统中的核心库存预扣等。在这些场景下，宁愿牺牲一点并发，也要保证数据的绝对正确性。
  • 短事务，且预期冲突概率高：如果业务逻辑很快就能完成，并且你知道这条数据很可能同时被多个请求操作，那么悲观锁可以有效避免复杂的冲突处理。

乐观锁（Optimistic Locking）

• 特点：它是一种“后知后觉”的策略。它假设冲突不常发生，所以不加锁，让大家自由操作。只有在提交更新时才检查数据是否被修改过。
• 优点：
  • 高并发性能：读取操作不加锁，大大提高了系统的吞吐量，尤其适合读多写少的场景。
  • 无死锁风险：因为不主动加锁，自然也就没有死锁的风险。
• 缺点：
  • 需要应用层处理冲突：如果更新失败（版本号不匹配），应用程序需要捕获异常，并决定是重试、报错还是其他策略。这增加了应用开发的复杂度。
  • 可能导致用户体验不佳：如果冲突频繁，用户可能会频繁遇到“数据已被修改，请重试”的提示。
  • 不适合高冲突场景：在高冲突场景下，大量的重试反而可能降低整体效率。
• 适用场景：
  • 低冲突、读多写少的场景：例如，用户个人信息编辑、文章编辑、商品详情页的更新等。这些场景下，数据被同时修改的概率相对较低。
  • 对响应速度要求高，允许少量重试的场景：如果系统需要快速响应，并且偶尔的冲突重试可以接受，乐观锁是个不错的选择。

我的看法是： 在实际项目中，我们往往会根据业务模块的具体特性来选择。对于核心的、对数据一致性有苛刻要求的业务（比如支付、库存），我更倾向于使用悲观锁，或者至少是结合

SELECT ... FOR UPDATE

进行关键操作。而对于那些非核心、或者读多写少的业务，乐观锁无疑是提升系统并发能力的利器。有时候，甚至可以在一个复杂的业务流程中，将两者结合起来，对核心数据使用悲观锁，对非核心数据使用乐观锁，这才是最灵活和高效的策略。

Sudowrite

对用户最友好的ai写作工具

74

查看详情

在实际应用中，如何有效避免或解决MySQL并发更新导致的死锁？

死锁，是并发更新中一个让人头疼的问题。当两个或多个事务互相持有对方需要的锁，并且都在等待对方释放锁时，就会发生死锁。MySQL的InnoDB引擎虽然有自动检测和回滚死锁事务的能力，但作为开发者，我们更应该追求“防患于未然”，尽可能地避免死锁的发生。

1. 保持事务短小精悍

这是最基本也最重要的一条原则。事务越长，持有锁的时间就越久，发生死锁的概率也就越大。尽量将不必要的业务逻辑（如网络请求、复杂计算）放在事务之外，只在事务内执行必要的数据库操作。

2. 统一加锁顺序

如果你的事务需要获取多个资源的锁（比如更新多张表或多行数据），务必确保所有事务都以相同的顺序获取这些锁。这是避免死锁最有效的策略之一。 举个例子，如果事务A先锁行1再锁行2，那么事务B也应该先锁行1再锁行2。如果事务B先锁行2再锁行1，就可能出现死锁。

3. 避免不必要的锁

• 使用行锁而非表锁：尽可能让MySQL使用行级锁而不是表级锁。确保你的

  WHERE

  子句能够命中索引，这样MySQL才能精确地锁定需要的行，而不是整个表。

• 减少锁粒度：只锁定你真正需要更新的行，而不是锁定整个数据集。
• 区分读写操作：对于纯粹的读操作，尽量利用MVCC机制，避免使用

  SELECT ... FOR UPDATE

  。

4. 索引优化

良好的索引设计对避免死锁至关重要。当

WHERE

子句没有命中索引时，MySQL可能会将行锁升级为表锁，或者锁定扫描过的所有行（间隙锁），这大大增加了死锁的风险。确保所有用于

WHERE

条件的字段都有合适的索引。

5. 降低隔离级别（谨慎使用）

在某些对数据一致性要求不是极高的场景下，可以考虑将事务隔离级别从

REPEATABLE READ

降低到

READ COMMITTED

。

READ COMMITTED

在每次读取时都会重新生成

Read View

，这意味着它能读取到其他已提交事务的最新数据，可能减少锁的持有时间，从而降低死锁风险。但请注意，这会引入不可重复读的问题，需要根据业务权衡。

6. 应用程序层面的重试机制

即使我们做了很多优化，死锁仍然可能发生。当InnoDB检测到死锁时，它会选择一个“牺牲者”事务并将其回滚。此时，应用程序需要捕获这个错误（例如SQLSTATE

40001

或错误码

1213

），然后进行重试。

• 重试策略：通常采用带指数退避的重试机制。即第一次重试等待短时间，如果再次失败，等待时间加倍，以此类推，直到达到最大重试次数或最大等待时间。这可以避免多个死锁事务同时重试，再次引发死锁。

7. 监控和分析死锁日志

定期检查MySQL的死锁日志（

SHOW ENGINE INNODB STATUS

命令的

LATEST DETECTED DEADLOCK

部分），分析死锁发生的原因、涉及的事务和资源。这能帮助我们发现潜在的死锁模式，并有针对性地进行优化。

在我看来，死锁的避免和解决是一个持续优化的过程。没有一劳永逸的方案，需要我们深入理解业务逻辑，结合数据库的特性，不断地调整和完善。最关键的还是那句话：统一加锁顺序，并保持事务足够短。 这两点做好了，大部分死锁问题都能迎刃而解。