从零起步学习MySQL 第十三章：MySQL 事务详解：原理、特性、并发问题与隔离级别

泯仲2026-03-17 9:53

引言

对于后端开发工程师而言，尤其是深耕 Java + MySQL 技术栈的开发者，"事务（Transaction）" 是绕不开的核心知识点，更是保证业务数据一致性的"生命线"。在实际业务场景中，无论是日常的银行转账、电商平台的库存扣减、订单支付流程，还是多表关联更新操作，一旦事务处理不当，就可能出现数据错乱、资金流失、业务异常等严重问题。

本节课我们将从后端开发实战角度，系统拆解 MySQL 事务的核心内容，从基础概念到底层原理，从并发问题到隔离级别，再到实战最佳实践，帮你彻底吃透事务，真正将其运用到项目开发中。本文核心内容包含：

  • 事务的本质定义（结合后端实战场景解读）

  • 事务 ACID 四大特性（拆解底层实现逻辑）

  • MySQL InnoDB 引擎事务核心实现机制（MVCC、redo/undo log、锁机制）

  • 并发事务常见的四大异常问题（附SQL示例）

  • MySQL 四大隔离级别（对比分析+适用场景）

  • 事务实战场景、常用SQL示例及Java中的事务控制方式

一、事务是什么？（后端实战视角直观解读）

事务（Transaction）本质上是一组不可分割的数据库操作集合，这组操作要么全部执行成功，要么全部执行失败，不存在"部分成功、部分失败"的中间状态。简单来说，事务就是"要么做完，要么不做"，以此保证业务数据的完整性和一致性。

举一个后端开发中最经典的场景------银行转账：

假设用户A要向用户B转账1000元，这个业务场景包含两个核心数据库操作：

  1. 用户A的账户余额减少1000元（UPDATE 操作）；

  2. 用户B的账户余额增加1000元（UPDATE 操作）。

如果这两个操作没有放在同一个事务中，可能会出现以下异常：用户A的余额减少了，但用户B的余额没有增加（比如中间出现数据库崩溃、网络中断），导致资金流失；或者用户B的余额增加了，而用户A的余额没有减少，导致银行亏损。

因此，必须将这两个操作纳入同一个事务中，确保要么两个操作都成功执行，要么都回滚到初始状态，避免数据错乱。

这里需要注意一个关键知识点：在 MySQL 中，只有 InnoDB 引擎支持事务，MyISAM 引擎不支持事务（这也是 InnoDB 成为后端开发主流引擎的核心原因之一）。InnoDB 引擎通过一系列底层机制，保证了事务的原子性、隔离性和持久性，为业务可靠性提供了支撑。

二、事务的四大特性（ACID）------事务的核心灵魂

事务的核心价值在于保证数据一致性，而这一价值的实现，依赖于 ACID 四大特性。这四个特性相互关联、相互支撑，共同构成了事务的完整体系，也是后端开发中判断事务是否可靠的核心标准。

A - 原子性（Atomicity）：要么全成，要么全败

原子性是事务最基础的特性，指事务中的所有操作是一个不可分割的整体，一旦事务开始执行，就必须要么全部执行完成并提交，要么在出现异常时全部回滚，不会留下任何中间状态。

比如上面的转账案例，若执行过程中出现数据库崩溃，原子性会保证：用户A的余额不会减少，用户B的余额也不会增加，数据恢复到转账前的状态。

底层实现：MySQL InnoDB 引擎通过 undo log（回滚日志） 实现原子性。undo log 会记录事务执行前的数据版本，当事务需要回滚时，InnoDB 会通过 undo log 恢复数据到修改前的状态，从而保证事务的原子性。

C - 一致性（Consistency）：数据始终合法

一致性指事务执行前后，数据库中的数据必须处于合法的状态，符合业务规则和数据约束（如主键唯一、非空约束、外键约束、业务逻辑约束等），不会出现"非法数据"。

举个例子：电商平台的库存管理中，库存字段的值不能为负数，这就是一种业务一致性约束。如果一个事务执行后，库存变成了负数，就违反了一致性要求，这样的事务是不被允许的，会被回滚。

需要注意的是，一致性是事务的最终目标，而原子性、隔离性、持久性都是为了保证一致性而存在的手段。也就是说，只要保证了原子性、隔离性和持久性，就能间接保证数据的一致性。

I - 隔离性（Isolation）：并发事务互不干扰

在后端项目中，数据库往往会被多个并发请求访问，多个事务会同时执行（比如多个用户同时下单、同时转账）。隔离性就是指，并发执行的多个事务之间相互隔离，一个事务的执行不会被其他事务干扰，每个事务都感觉自己是"单独在操作数据库"。

不同的隔离级别，决定了事务之间"看到对方修改数据"的程度。隔离级别越低，事务并发性能越高，但数据一致性越难保证；隔离级别越高，数据一致性越好，但并发性能越低。后续我们会详细讲解 MySQL 的四大隔离级别。

D - 持久性（Durability）：提交即永久

持久性指事务一旦提交成功，其对数据库的修改就会永久保存，即使后续出现数据库崩溃、服务器宕机等异常情况，数据也不会丢失。

比如转账事务提交后，用户A和用户B的余额修改就会永久生效，即使此时数据库崩溃，重启后数据依然是修改后的状态，不会恢复到转账前。

底层实现：MySQL InnoDB 引擎通过 redo log（重做日志） 和 WAL（Write-Ahead Logging，预写日志） 机制实现持久性。核心逻辑是：事务提交时，InnoDB 不会先将数据直接写入磁盘（而是先存在 Buffer Pool 缓冲区），而是先将数据修改记录写入 redo log，待 redo log 写入完成后，就认为事务提交成功；即使后续系统崩溃，重启后 InnoDB 会通过 redo log 重新执行修改操作，恢复数据，从而保证持久性。

三、MySQL（InnoDB）的事务实现关键机制

InnoDB 引擎之所以能完美支持 ACID 特性，成为后端开发的首选引擎，核心在于其底层的五大关键机制。这些机制相互配合，既保证了事务的可靠性，又兼顾了并发性能，是我们理解 MySQL 事务的核心重点。

3.1 redo log（重做日志）------持久性的"守护者"

redo log 是 InnoDB 引擎用于保证事务持久性的核心日志，其核心作用是"记录数据修改的动作"，以便在系统崩溃后，能够通过重做这些动作，恢复数据。

我们可以简单理解为：redo log 就像一个"记事本"，事务执行过程中，每一次数据修改（INSERT、UPDATE、DELETE）都会被记录到这个"记事本"中；当事务提交时，InnoDB 会确保 redo log 中的记录被写入磁盘（持久化），然后才会返回"提交成功"的结果。即使此时数据库崩溃，重启后 InnoDB 会读取 redo log，将所有已提交事务的修改重新执行一遍，确保数据不丢失。

补充细节：redo log 是循环写入的，有固定的大小限制，当 redo log 写满后，InnoDB 会暂停新的写入操作，先将 redo log 中的记录同步到磁盘数据文件中，清空 redo log 后再继续写入，这个过程称为" checkpoint（检查点）"。

3.2 undo log（回滚日志）------原子性与 MVCC 的"基石"

undo log 与 redo log 作用相反，redo log 记录"数据修改后的状态"，用于恢复已提交的数据；而 undo log 记录"数据修改前的状态"，主要用于两个场景：

  1. 事务回滚：当事务执行过程中出现异常（如报错、手动回滚），InnoDB 会通过 undo log 恢复数据到修改前的状态，保证事务的原子性；

  2. 支持 MVCC：MVCC（多版本并发控制）是 InnoDB 提高并发性能的核心机制，其读取旧版本数据的功能，就是通过 undo log 实现的（undo log 会保存数据的多个历史版本）。

举个例子：当我们执行 UPDATE users SET name='A2' WHERE id=1 时，undo log 会记录 id=1 的用户在修改前的 name 值（比如 'A1'）；如果事务需要回滚，InnoDB 就会通过 undo log 将 name 恢复为 'A1'；如果有其他事务需要读取该用户的旧版本数据，也可以通过 undo log 获取。

3.3 MVCC（多版本并发控制）------高并发的"核心密码"

在高并发场景下，如果多个事务同时读写同一份数据，很容易出现锁冲突，导致并发性能下降。MVCC 的核心作用就是"在不加锁的情况下，实现读写分离"，让读操作不会被写操作阻塞，写操作也不会被读操作阻塞，从而大幅提升数据库的并发性能。

MVCC 的核心原理是：InnoDB 会为每一行数据添加两个隐藏字段------事务ID（trx_id） 和 回滚指针（roll_ptr）。事务ID 用于标识修改该行数据的事务，回滚指针用于指向该行数据的上一个版本（存储在 undo log 中）。

当事务执行读操作时，InnoDB 会根据当前事务的 ID，读取符合条件的"历史版本数据"（而非当前正在修改的数据），这样就实现了"快照读"------读操作无需加锁，也不会被写操作阻塞；而写操作只会修改当前版本的数据，并生成新的版本，不会影响其他事务的读操作。

补充：MVCC 仅支持 InnoDB 引擎的 READ COMMITTED 和 REPEATABLE READ 两个隔离级别，这也是这两个隔离级别并发性能较好的原因。

3.4 行级锁 / 间隙锁 / Next-Key Lock------隔离性的"保障"

虽然 MVCC 能解决大部分读写并发问题，但在某些场景下（如并发写操作），依然需要通过锁机制来保证隔离性，避免并发异常。InnoDB 支持三种常见的锁类型，用于不同的并发场景：

  1. 行锁（Record Lock）：最细粒度的锁，仅锁住某一行数据。比如执行 UPDATE users SET name='A2' WHERE id=1 时，InnoDB 会对 id=1 的这一行加行锁，其他事务只能等待该锁释放后，才能修改这一行数据；但其他行的数据不受影响，并发性能较高。

  2. 间隙锁（Gap Lock）：锁住某一段数据范围，但不锁具体的行。比如执行 SELECT * FROM users WHERE age BETWEEN 18 AND 25 FOR UPDATE 时，InnoDB 会锁住 age 在 18~25 之间的所有间隙（包括 18 以下和 25 以上的相邻间隙），防止其他事务在这个范围内插入新的数据，主要用于避免幻读。

  3. Next-Key Lock = 行锁 + 间隙锁：InnoDB 的默认锁机制，既锁住具体的行，也锁住该行相邻的间隙。比如锁住 id=1 的行时，同时会锁住 id<1 和 1<id<2 的间隙，进一步防止幻读，是 InnoDB 解决幻读的核心手段。

补充：间隙锁和 Next-Key Lock 仅在 REPEATABLE READ（MySQL 默认隔离级别）及以上级别生效，READ COMMITTED 级别下不会生效。

3.5 自动死锁检测------并发异常的"自救机制"

在并发场景下，两个或多个事务可能会互相等待对方释放锁，从而陷入"死锁"状态。比如：

  • 事务T1：锁住 id=1 的行，等待锁住 id=2 的行；

  • 事务T2：锁住 id=2 的行，等待锁住 id=1 的行。

此时两个事务会互相等待，永远无法继续执行，若不处理，会导致数据库资源被占用，影响其他事务。InnoDB 引擎内置了自动死锁检测机制，会定期检测事务之间的锁等待关系，当发现死锁时，会主动回滚其中一个"代价较小"的事务（比如执行时间较短、修改数据较少的事务），释放锁资源，让另一个事务继续执行，从而避免死锁持续影响系统。

四、并发事务可能引发的问题（四大并发异常）

在并发场景下，多个事务同时执行时，如果没有合适的隔离级别和锁机制，就可能出现各种并发异常。这四大异常是理解隔离级别的基础，也是后端开发中需要重点规避的问题，每一种异常都对应着实际业务中的潜在风险。

4.1 脏读（Dirty Read）------读取到"未提交的脏数据"

脏读是指一个事务读取到了另一个事务"未提交"的数据。由于未提交的数据可能会被回滚，因此读取到的"脏数据"是不可靠的，可能会导致后续业务逻辑出错。

示例（附SQL）：

sql 复制代码 
-- 事务T1（未提交）
START TRANSACTION;
UPDATE users SET name='A2' WHERE id = 1;  -- 修改id=1的用户姓名为A2，未提交

-- 事务T2（读取T1未提交的数据）
SELECT name FROM users WHERE id = 1;  -- 读取到name='A2'（脏读）

-- 此时T1执行回滚
ROLLBACK;

-- T2再次读取
SELECT name FROM users WHERE id = 1;  -- 读取到name='A1'（数据回滚，之前读取的是脏数据）

风险：如果 T2 根据读取到的"脏数据"执行后续操作（比如根据 name='A2' 进行业务判断），而 T1 最终回滚，会导致 T2 的业务逻辑出错，数据不一致。

4.2 不可重复读（Non-repeatable Read）------同一事务内读取结果不一致

不可重复读是指在同一个事务内，多次读取同一行数据，得到的结果不一致。这种异常的原因是：在两次读取之间，有其他事务修改了该行数据并提交。

示例（附SQL）：

sql 复制代码 
-- 事务T1（开始执行）
START TRANSACTION;
SELECT name FROM users WHERE id = 1;  -- 第一次读取，结果为'Alice'

-- 事务T2（修改并提交）
START TRANSACTION;
UPDATE users SET name='Bob' WHERE id = 1;
COMMIT;

-- 事务T1（再次读取同一行）
SELECT name FROM users WHERE id = 1;  -- 第二次读取，结果为'Bob'（不可重复读）
COMMIT;

注意：不可重复读和脏读的区别在于：脏读读取的是"未提交"的数据，而不可重复读读取的是"已提交"的数据，只是两次读取之间数据被修改了。

4.3 幻读（Phantom Read）------同一事务内结果集行数不一致

幻读是指在同一个事务内，两次执行相同的查询语句，得到的结果集行数或内容不一致。这种异常的原因是：在两次查询之间，有其他事务插入或删除了符合查询条件的数据并提交。

示例（附SQL）：

sql 复制代码 
-- 事务T1（开始执行）
START TRANSACTION;
SELECT * FROM orders WHERE status='PENDING';  -- 第一次查询，结果为5行（待处理订单）

-- 事务T2（插入新数据并提交）
START TRANSACTION;
INSERT INTO orders (order_no, status) VALUES ('ORDER123', 'PENDING');
COMMIT;

-- 事务T1（再次执行相同查询）
SELECT * FROM orders WHERE status='PENDING';  -- 第二次查询，结果为6行（出现"幻影"数据，幻读）
COMMIT;

注意：幻读和不可重复读的区别在于：不可重复读是"同一行数据被修改"，而幻读是"新增或删除了符合条件的行"，导致结果集行数变化。

4.4 丢失更新（Lost Update）------并发写操作覆盖问题

丢失更新是指两个事务同时读取到同一份数据，分别对其进行修改，最终后提交的事务会覆盖先提交事务的修改，导致先提交事务的修改"丢失"。

示例（附SQL）：

sql 复制代码 
-- 商品表product，id=1的商品库存为10
SELECT stock FROM product WHERE id=1;  -- 初始库存10

-- 事务T1（读取库存）
START TRANSACTION;
SELECT stock FROM product WHERE id=1;  -- 读取到stock=10

-- 事务T2（读取库存）
START TRANSACTION;
SELECT stock FROM product WHERE id=1;  -- 读取到stock=10

-- 事务T2（修改库存并提交）
UPDATE product SET stock=9 WHERE id=1;  -- 库存改为9
COMMIT;

-- 事务T1（修改库存并提交）
UPDATE product SET stock=9 WHERE id=1;  -- 再次改为9，覆盖了T2的修改（T2的修改丢失）
COMMIT;

风险：这种异常在电商库存扣减、积分修改等场景中非常危险，可能导致库存超卖、积分计算错误等严重问题。

五、MySQL 四种隔离级别（重点，后端开发必记）

为了解决上述并发异常问题，SQL 标准定义了四种隔离级别，MySQL InnoDB 引擎完全支持这四种隔离级别。不同隔离级别对应着不同的并发性能和数据一致性，后端开发者需要根据业务场景，选择合适的隔离级别（核心是"平衡性能和一致性"）。

下面我们逐一解读四种隔离级别，结合其特点、解决的并发问题、适用场景进行详细说明：

★ 1. READ UNCOMMITTED（读未提交）------最低隔离级别

核心特点：允许一个事务读取另一个事务未提交的数据。

并发异常：允许脏读、不可重复读、幻读（所有异常都可能出现）。

性能：最高（无需加锁，无需等待其他事务提交）。

适用场景：几乎没有适用场景，仅在对数据一致性要求极低、追求极致并发性能的场景下可能使用（如临时统计数据，允许误差），后端开发中基本不用。

★ 2. READ COMMITTED（读已提交）------Oracle 默认隔离级别

核心特点：一个事务只能读取另一个事务"已提交"的数据，禁止读取未提交的数据。

并发异常：解决了脏读，但仍可能出现不可重复读、幻读。

性能：较高（读操作无需加锁，写操作仅加行锁）。

适用场景：对数据一致性有一定要求，但又需要较好并发性能的场景，如电商订单查询、用户信息查询等。很多互联网项目会选择这个隔离级别，平衡性能和一致性。

★ 3. REPEATABLE READ（可重复读）------MySQL 默认隔离级别

核心特点：同一个事务内，多次读取同一批数据，得到的结果始终一致（即使其他事务修改了数据并提交，也不会影响当前事务的读取结果）。

并发异常：解决了脏读、不可重复读；在 InnoDB 引擎中，通过 MVCC + Next-Key Lock 机制，可防止"多数场景下的幻读"（仅极端场景可能出现幻读）。

性能：中等（读操作通过 MVCC 实现无锁，写操作加行锁或 Next-Key Lock）。

适用场景：MySQL 后端开发的默认选择，适用于大多数业务场景（如库存管理、订单支付、用户账户操作等），既能保证数据一致性，又能兼顾并发性能。

★ 4. SERIALIZABLE（串行化）------最高隔离级别

核心特点：所有事务串行执行（一个事务执行完成后，另一个事务才能开始执行），相当于给整个数据库加了"全局锁"。

并发异常：完全解决所有并发异常（脏读、不可重复读、幻读都不会出现）。

性能：最低（并发性能极差，多个事务只能排队执行）。

适用场景：对数据一致性要求极高、不允许任何误差的场景，如银行转账、金融交易等核心业务，后端开发中仅少数场景会使用。

隔离级别解决并发问题能力总结（表格清晰对比）

隔离级别 脏读 不可重复读 幻读
READ UNCOMMITTED（读未提交） 允许 允许 允许
READ COMMITTED（读已提交） 禁止 允许 允许
REPEATABLE READ（MySQL 默认） 禁止 禁止 多数情况禁止
SERIALIZABLE（串行化） 禁止 禁止 禁止

六、MySQL 中设置隔离级别（实战操作）

后端开发中，我们需要根据业务需求，灵活设置 MySQL 的事务隔离级别。MySQL 支持两种设置范围：会话级别 （仅当前会话有效）和 全局级别（所有会话有效），实际开发中多使用会话级别（避免影响其他业务）。

6.1 查看当前隔离级别

执行以下 SQL 语句，查看当前会话的隔离级别：

sql 复制代码 
SELECT @@transaction_isolation;

补充：MySQL 8.0 之前的版本，使用 SELECT @@tx_isolation; 查看，两种方式均可兼容。

6.2 设置隔离级别

  1. 会话级别（推荐）：仅对当前会话生效，重启会话后恢复默认值（REPEATABLE READ）。
sql 复制代码 
-- 设置为 READ COMMITTED 隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 开启事务
START TRANSACTION;
-- 执行数据库操作
UPDATE ...;
SELECT ...;
-- 提交事务
COMMIT;
  1. 全局级别：对所有新会话生效，已存在的会话不受影响，重启 MySQL 后恢复默认值。
sql 复制代码 
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

注意：设置隔离级别后，需要开启新的事务，隔离级别才会生效；如果事务已经开启，设置的隔离级别对当前事务无效。

七、常用场景与最佳实践（后端开发必用）

掌握了事务的基础知识点和隔离级别后，更重要的是在实际项目中合理运用事务，规避并发问题，提升系统性能。下面结合后端开发中最常见的场景，分享事务的最佳实践和常用操作。

7.1 悲观锁（SELECT ... FOR UPDATE）------防止并发写冲突

悲观锁的核心思想是"先上锁，再操作"，认为并发写冲突一定会发生，因此在读取数据时就对数据加锁，防止其他事务修改该数据，适用于并发写冲突频繁的场景（如库存扣减、订单支付）。

实战示例（库存扣减，避免丢失更新）

sql 复制代码 
-- 开启事务
START TRANSACTION;
-- 读取库存并加行锁（FOR UPDATE 会对查询到的行加行锁）
SELECT stock FROM items WHERE id = 1 FOR UPDATE;
-- 扣减库存（此时其他事务无法修改id=1的库存，直到当前事务提交）
UPDATE items SET stock = stock - 1 WHERE id = 1;
-- 提交事务，释放锁
COMMIT;

注意：FOR UPDATE 仅在事务中生效，事务提交或回滚后，锁会自动释放；如果查询不到数据（如 id=1 不存在），则不会加锁。

7.2 乐观锁（基于 version 字段）------高并发读场景优选

乐观锁的核心思想是"先操作，后校验"，认为并发写冲突很少发生，因此不主动加锁，而是通过一个"版本号"字段，校验数据是否被其他事务修改，适用于读多写少的场景（如商品详情查询、用户信息修改）。

实现步骤：

  1. 在表中添加 version 字段（初始值为 1）；

  2. 读取数据时，同时读取 version 字段；

  3. 修改数据时，校验当前 version 是否与读取时的 version 一致，一致则修改并递增 version，不一致则说明数据已被修改，需要重试。

实战示例（商品库存扣减，乐观锁实现）：

sql 复制代码 
-- 读取数据（获取当前库存和版本号）
SELECT stock, version FROM product WHERE id = 1;  -- 假设 stock=10，version=1

-- 修改数据（校验版本号）
UPDATE product 
SET stock = stock - 1, version = version + 1
WHERE id = 1 AND version = 1;  -- 仅当version=1时才修改

-- 判断修改是否成功（影响行数为1则成功，为0则失败，需要重试）
-- 若影响行数为0，说明其他事务已修改该数据，需重新读取数据后重试

优势：无需加锁，并发性能高；劣势：需要手动处理重试逻辑，适用于冲突较少的场景。

7.3 避免事务中执行耗时操作------减少锁占用时间

事务执行期间，会持有相关的锁资源，如果事务中包含耗时操作，会导致锁长时间被占用，增加死锁风险，降低系统并发性能。因此，事务中应尽量避免以下操作：

  • 网络调用（如调用第三方接口、跨服务请求）；

  • 文件 I/O（如读写本地文件、上传下载文件）；

  • 大量循环操作（如批量处理大量数据，可拆分到事务外执行）；

  • 人为等待（如线程睡眠、用户输入等待）。

最佳实践：将耗时操作移到事务外部，事务仅包含核心的数据库操作，确保事务快速执行、快速释放锁。

7.4 捕获死锁并重试------提升系统稳定性

虽然 InnoDB 会自动检测死锁并回滚其中一个事务，但后端开发中，我们需要在业务层捕获死锁异常，并进行重试操作，避免业务中断。

Java 实战示例（Spring 框架中捕获死锁并重试）：

sql 复制代码 
@Transactional
public void updateStock(Long productId) {
    try {
        // 核心数据库操作（如库存扣减）
        productMapper.decreaseStock(productId);
    } catch (DeadlockLoserDataAccessException e) {
        // 捕获死锁异常，重试操作（可设置重试次数，避免无限重试）
        retry(updateStock(productId), 3);  // 重试3次
    }
}

// 重试工具方法
private void retry(Runnable task, int retryCount) {
    if (retryCount <= 0) {
        throw new RuntimeException("重试次数耗尽，操作失败");
    }
    try {
        task.run();
    } catch (DeadlockLoserDataAccessException e) {
        retry(task, retryCount - 1);
    }
}

八、总结

本节课我们系统讲解了 MySQL 事务的核心内容，从基础概念到实战实践，覆盖了后端开发中必须掌握的知识点，这里做一个重点回顾，帮助大家快速梳理记忆：

  1. 事务的本质：一组不可分割的数据库操作，要么全部成功、要么全部失败，是保证数据一致性的核心机制。

  2. ACID 四大特性：原子性（undo log 支持）、一致性（最终目标）、隔离性（锁+MVCC 支持）、持久性（redo log 支持）。

  3. InnoDB 核心机制：redo log（持久化）、undo log（原子性+MVCC）、MVCC（高并发）、锁机制（隔离性）、自动死锁检测（容错）。

  4. 四大并发异常：脏读、不可重复读、幻读、丢失更新，需根据隔离级别规避。

  5. 四大隔离级别：读未提交（不用）、读已提交（常用）、可重复读（MySQL 默认）、串行化（少数场景用），核心是平衡性能和一致性。

  6. 实战最佳实践：悲观锁（写冲突多）、乐观锁（读多写少）、避免事务中耗时操作、捕获死锁并重试。

事务是后端开发中不可或缺的知识点，尤其是在高并发、数据一致性要求高的业务场景中，能否合理运用事务，直接决定了系统的可靠性和稳定性。建议大家结合实际项目，多动手实践，熟练掌握事务的用法和底层原理，避免出现数据错乱等严重问题。

下一节课，我们将讲解 MySQL 事务的进阶内容，包括分布式事务、事务隔离级别的底层实现细节，敬请期待！

相关推荐
嚴寒2 小时前
云服务核心组件：OSS 与 RDS 全面指南（2026版）
数据库·后端·架构
G探险者2 小时前
DDD开发模式说明
java·运维·数据库
TDengine （老段）2 小时前
TDengine IDMP 组态面板 —— 图元
大数据·数据库·人工智能·物联网·时序数据库·tdengine
马里马里奥-2 小时前
文献阅读：LinkAlign：面向真实世界大规模多数据库文本转SQL任务的可扩展模式链接方法
数据库·sql
FITA阿泽要努力2 小时前
《通过实战SQL学会CTE、CURRENT_DATE、CURDATE()、DATE_SUB与缩进&注释的问题》
数据库
爬山算法2 小时前
MongoDB（42）如何使用$project阶段？
数据库·mongodb
西门吹雪分身2 小时前
ShardingSphere-JDBC水平分片
mysql·shardingjdbc
0xDevNull2 小时前
MySQL的索引下推（ICP）
sql·mysql
式5162 小时前
CUDA编程学习（五）线程模型定义、矩阵相加
学习·算法·矩阵
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03OpenClaw 使用和管理 MCP 完全指南04OpenClaw Control UI安全上下文访问配置05UV安装并设置国内源06本地部署 OpenClaw + DeepSeek-R1 完全指南07OpenClaw macOS 完整安装与本地模型配置教程（实战版）08Openclow安装保姆级教程09Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services10让 Trae IDE 智能体 “读懂”文档 Excel+PDF+DOCX ：mcp-documents-reader 工具使用指南