MySQL脏读不可重复读避免方法

原创于 2025-05-29 09:37:32 发布 · 534 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

学习笔记专栏收录该内容

229 篇文章

订阅专栏

在 MySQL 中，避免脏读（Dirty Read）和不可重复读（Non-Repeatable Read）的核心在于正确设置事务的隔离级别以及合理利用锁机制。这两种现象都是由于并发事务执行时缺乏适当的隔离造成的。

以下是具体的避免方法：

🛡️ 1. 提升事务隔离级别

避免脏读： 将隔离级别设置为 READ COMMITTED 或更高。
- READ COMMITTED 级别保证了事务只能读取到已经提交的其他事务所做的修改。它通过在读取时获取行级共享锁（但通常在读取后立即释放） 或者（在 InnoDB 中更常见）使用多版本并发控制（MVCC） 来实现。当一个事务修改数据但未提交时，其他事务在 READ COMMITTED 下无法看到这些未提交的修改。
避免不可重复读： 将隔离级别设置为 REPEATABLE READ 或更高（如 SERIALIZABLE）。
- REPEATABLE READ 级别保证了在同一个事务中，多次读取同一行数据的结果是一致的（可重复的）。在 InnoDB 存储引擎（MySQL 默认引擎）中，这是通过 MVCC 实现的：
  - 当一个事务开始时（执行第一个 SELECT 语句时），它会获得一个数据库当前状态的"一致性快照"（Read View）。
  - 在该事务后续的所有普通 SELECT 语句（非加锁读） 中，都会基于这个快照来读取数据，即使其他事务在此期间修改并提交了数据，该事务看到的仍然是它开始时那个快照版本的数据，从而避免了不可重复读。
  - 注意： UPDATE, DELETE, SELECT ... FOR UPDATE/SHARE 等操作看到的是最新的已提交数据，因为它们需要影响最新的数据状态，所以在一个 REPEATABLE READ 事务内进行更新操作时，可能会基于最新的数据修改，这可能导致"幻读"（Phantom Read）现象（InnoDB 的 REPEATABLE READ 通过 Next-Key Locks 通常可以防止幻读）。
- SERIALIZABLE 级别通过强制事务串行执行来提供最强的隔离性，自然避免了脏读和不可重复读（以及幻读），但并发性能代价最高。

🧩 2. 利用 InnoDB 的 MVCC (多版本并发控制)

如上面所述，InnoDB 的 REPEATABLE READ 和 READ COMMITTED 隔离级别都利用 MVCC 来实现非阻塞的一致性读。
READ COMMITTED 下的 MVCC： 每个普通的 SELECT 语句都会获取一个新的一致性快照（Read View）。这意味着在同一事务内，不同的 SELECT 语句可能看到不同的已提交数据版本，这可能导致不可重复读，但避免了脏读（因为只看到已提交版本）。
REPEATABLE READ 下的 MVCC： 事务在第一次执行普通 SELECT 时获取一个一致性快照（Read View），并在整个事务期间使用这个相同的快照进行后续的所有普通 SELECT 操作。这保证了在同一个事务内多次读取相同数据的结果绝对一致，避免了不可重复读（同时也避免了脏读）。

🔒 3. 显式使用锁 (悲观锁)

即使设置了较高的隔离级别，有时也需要在事务内对特定数据进行显式锁定，以确保操作的绝对安全或处理特殊的冲突场景。
避免脏读（显式锁）： 脏读通常通过设置合适的隔离级别（READ COMMITTED）就能有效避免，显式锁不是主要手段。
避免不可重复读（显式锁）：
- SELECT ... FOR SHARE (旧版 SELECT ... LOCK IN SHARE MODE): 在读取数据时，为这些行设置共享锁（S Lock）。这会阻止其他事务对这些行进行修改（需要获取排他锁 X Lock），但允许其他事务读取（也获取共享锁）。如果在一个事务中先使用 SELECT ... FOR SHARE 读取数据，那么在该事务提交或回滚前，其他事务无法修改这些数据，从而保证了后续在同一个事务中再次读取时值不会改变。
- SELECT ... FOR UPDATE: 在读取数据时，为这些行设置排他锁（X Lock）。这会阻止其他事务读取（尝试加共享锁）或修改（尝试加排他锁）这些行。这是最严格的锁，也能防止不可重复读（同时防止脏读和幻读）。
使用显式锁的注意事项：
- 需要在事务中显式使用（START TRANSACTION 或 BEGIN）。
- 会显著降低并发性能，因为锁会阻塞其他事务。
- 需要仔细设计加锁范围和顺序，避免死锁。
- 通常在高隔离级别（REPEATABLE READ）下配合 MVCC 的非锁定读（普通 SELECT）就能满足避免不可重复读的需求，显式锁用于特定需要强制同步的场景。

📌 总结与最佳实践

理解默认行为： MySQL InnoDB 的默认隔离级别是 REPEATABLE READ。这已经能够同时避免脏读和不可重复读（并且在很大程度上防止了幻读）。对于大多数应用场景，使用默认隔离级别是安全且性能较好的选择。
避免脏读：
- 确保隔离级别至少是 READ COMMITTED。REPEATABLE READ 和 SERIALIZABLE 自然满足。
- 默认的 REPEATABLE READ 即可有效避免。
避免不可重复读：
- 将隔离级别设置为 REPEATABLE READ（推荐）或 SERIALIZABLE。READ COMMITTED 无法避免不可重复读。
- 默认的 REPEATABLE READ 利用 MVCC 的"一致性快照"读，完美避免不可重复读。
谨慎使用显式锁 (FOR SHARE/FOR UPDATE)：
- 仅在明确需要在同一事务内确保后续操作依赖的读取数据绝对不被修改，或者需要基于最新数据进行更新并防止冲突时使用。
- 优先考虑依赖 REPEATABLE READ 的 MVCC 机制进行普通的非锁定读。
权衡性能与一致性： 隔离级别越高，一致性越强，但并发性能通常越低（锁竞争、回滚段维护等开销）。根据业务场景的敏感度选择最低必要的隔离级别。例如：
- 对数据一致性要求极高的金融交易：REPEATABLE READ（默认）或必要时 SERIALIZABLE。
- 报表查询（允许少量过时数据）：READ COMMITTED 甚至 READ UNCOMMITTED（但后者允许脏读，极少使用）。
明确事务边界： 使用 START TRANSACTION / BEGIN 显式开始事务，并尽快提交 (COMMIT) 或回滚 (ROLLBACK) 以缩短事务持有锁或快照的时间，提高并发性。

📖 关键点记忆：

脏读 = 读到了未提交的数据。 解决方案：隔离级别 >= READ COMMITTED (默认 REPEATABLE READ 已解决)。
不可重复读 = 同一事务内读同一数据两次，结果不同（其他已提交事务修改导致）。 解决方案：隔离级别 >= REPEATABLE READ (默认级别通过 MVCC 快照解决)。READ COMMITTED 无法解决。
默认的 REPEATABLE READ (InnoDB) 是避免这两种问题的首选方案。

通过合理配置事务隔离级别（通常保持默认的 REPEATABLE READ）和理解 InnoDB MVCC 的工作原理，你可以有效地避免 MySQL 中的脏读和不可重复读问题。仅在特定场景下才需要显式使用 SELECT ... FOR SHARE 或 SELECT ... FOR UPDATE。