当前位置：首页 > news >正文

11-MySQL事务管理

news 2025/11/2 15:11:31

💬 ：如果你在阅读过程中有任何疑问或想要进一步探讨的内容，欢迎在评论区畅所欲言！我们一起学习、共同成长~！
👍 ：如果你觉得这篇文章还不错，不妨顺手点个赞、加入收藏，并分享给更多的朋友噢~！

1. 事务的定义与核心 ACID 属性（面试必背）

1.1 事务的定义

事务是一组逻辑相关的 DML 语句（如 insert、update、delete）的集合，这组语句要么全部成功执行，要么全部失败回滚，最终数据库只会处于 “执行前” 或 “执行后” 的一致状态，不会停留在中间态。

例：删除学生信息时，需同时删除 “基本信息表”“成绩表”“论坛发帖表”，这 3 条delete语句需封装为一个事务。

1.2 ACID 属性详解（面试高频提问点）

ACID 是事务的 4 个核心特性，是判断事务机制是否完整的标准，必须准确理解并能举例说明。

1.2.1 原子性（Atomicity）：“要么全成，要么全不”

核心：事务中的所有操作是一个不可分割的整体，执行过程中若任意一步出错，已执行的操作会全部回滚，数据库恢复到事务开始前的状态。
例：转账场景（张三给李四转 100 元）：
- 正常流程：update account set blance=blance-100 where name='张三' → update account set blance=blance+100 where name='李四' → 提交（commit）；
- 异常场景：若第一条update执行成功，第二条因 “李四账号不存在” 失败，则事务回滚（rollback），张三的余额恢复为原始值，不会出现 “钱扣了没到账” 的情况。

1.2.2 一致性（Consistency）：“数据从一致到一致”

核心：事务执行前、后，数据库的完整性约束（如主键唯一、余额非负）不被破坏，数据始终处于 “合法状态”。
例：售票系统中，nums（库存）始终≥0；转账后，张三减少的余额 = 李四增加的余额，总余额不变。
注意：一致性需业务逻辑 + 事务机制共同保障（MySQL 提供原子性、隔离性、持久性来支撑一致性，业务逻辑需避免 “余额为负” 等非法操作）。

1.2.3 隔离性（Isolation）：“并发事务互不干扰”

核心：数据库允许多个并发事务同时读写同一份数据，隔离性防止事务因交叉执行导致数据不一致，确保一个事务的中间操作（未提交状态）不会被其他事务干扰。
例：客户端 A 修改库存但未提交时，客户端 B 无法读取 A 的未提交结果，避免 “超卖”。

1.2.4 持久性（Durability）：“提交后数据永久”

核心：事务一旦执行commit（提交），对数据的修改会永久保存到磁盘，即使后续系统崩溃（如断电、服务器宕机），数据也不会丢失。
反例：若事务未提交（仅在内存中修改），系统崩溃后修改会丢失；提交后则无论何种故障，数据都已固化到磁盘。

2. MySQL 事务的支持与基础配置

MySQL 并非所有存储引擎都支持事务，且事务提交方式可配置，这是面试中 “引擎差异” 考点的核心。

2.1 引擎支持：仅 InnoDB 支持事务

MySQL 常见引擎中，只有 InnoDB 支持事务，MyISAM、MEMORY 等引擎均不支持（面试常考引擎差异）。

2.1.1 查看数据库引擎

-- 方式1：表格形式显示所有引擎
show engines;-- 方式2：行形式显示（更清晰查看事务支持）
show engines \G;

执行结果中，Transactions字段为YES表示支持事务，该字段为NO表示不支持事务。

2.1.2 InnoDB 与 MyISAM 的事务支持差异（面试必答）

对比维度	InnoDB	MyISAM
事务支持	支持	不支持
锁粒度	行级锁（并发效率高）	表级锁（并发效率低）
外键支持	支持	不支持
崩溃恢复	支持（基于日志）	不支持

2.2 事务提交方式：自动提交 vs 手动提交

MySQL 默认开启 “自动提交”（即每条 DML 语句单独作为一个事务，执行后自动commit），但实际业务中需手动控制事务（如多步操作封装为一个事务）。

2.2.1 查看自动提交状态

show variables like 'autocommit';

结果Value=ON：开启自动提交；
结果Value=OFF：关闭自动提交。

2.2.2 修改自动提交状态（笔试必写）

-- 1. 关闭自动提交（当前会话生效，重启客户端后恢复默认）
SET AUTOCOMMIT=0;-- 2. 开启自动提交（恢复默认）
SET AUTOCOMMIT=1;

关键注意：一旦执行begin或start transaction，无论autocommit是否开启，事务都必须手动commit才会持久化。

3. 事务的常见操作

事务操作的核心流程为：开启事务 → 执行 DML → 提交 / 回滚，需掌握关键 SQL 语法及实战场景。

3.1 基础操作语法（笔试必写）

操作目的	SQL 语句	说明
开启事务	`begin;` 或 `start transaction;`	两种写法等价，推荐`begin;`
创建保存点	`savepoint 保存点名;`	插入记录前创建保存点，用于部分回滚（如回滚到某个中间状态）
回滚到保存点	`rollback to 保存点名;`	仅回滚保存点之后的操作（即仅删除该保存点后的操作）
全量回滚	`rollback;`	回滚事务中所有操作（即删除所有操作。未提交前有效）
提交事务	`commit;`	持久化事务中所有操作

3.2 实战案例：account 表的事务操作

以 “银行账户表” 为例，演示事务的完整流程。

3.2.1 步骤 1：创建支持事务的 account 表（必写引擎 InnoDB）

3.2.2 步骤 2：正常事务流程（插入→部分回滚→全回滚）

-- 1. 查看自动提交状态（默认ON，不影响begin的手动提交）
show variables like 'autocommit';  -- 结果Value=ON-- 2. 开启事务
begin;-- 3. 创建保存点save1（插入第一条记录前）
savepoint save1;-- 4. 插入第一条记录
insert into account values (1, '张三', 100.00);-- 5. 创建保存点save2（插入第二条记录前）
savepoint save2;-- 6. 插入第二条记录
insert into account values (2, '李四', 10000.00);-- 7. 查看当前数据（事务内可见，未持久化）
select * from account;  -- 8. 回滚到save2（仅删除save2后的记录）
rollback to save2;-- 9. 再次查看
select * from account;  -- 仅保留save2前的记录-- 10. 全量回滚（删除所有操作，回到事务开始前）
rollback;-- 11. 最终查看（无数据，事务未提交）
select * from account;  -- 结果：Empty set

3.2.3 步骤 3：异常场景验证（未提交崩溃自动回滚）

终端 A 操作：

begin;
insert into account values (1, '张三', 100.00);  -- 未commit

终端 B 查看（隔离级别为 “读未提交” 时可见，见第 4 章）：
```
select * from account;  -- 可见张三的记录（未持久化）
```

终端 A 异常崩溃（如ctrl+\终止 MySQL），终端 B 再次查看：

select * from account;  -- 结果：Empty set（MySQL自动回滚未提交事务）

3.2.4 步骤 4：提交后持久化（验证持久性）

begin;
insert into account values (1, '张三', 100.00);
commit;  -- 提交事务-- 终端A崩溃后，终端B查看
select * from account;  -- 结果：张三100（数据已持久化，不会丢失）

事务提交/回滚后自动清理保存点，只有事务未结束但某个保存点 “后续不再需要”时通过 release savepoint 保存点名; 手动删除保存点。

4. 事务隔离级别（面试高频）

4.1 隔离级别的核心作用

多个事务并发执行时，隔离级别决定了 “一个事务能否读取另一个事务的未提交 / 已提交数据”，从而解决 “脏读”“不可重复读”“幻读” 三类并发问题。

4.2 三类并发问题

脏读：读取到其他事务未提交的 “临时数据”（如 A 修改未提交，B 读到 A 的修改，后 A 回滚，B 读的是 “脏数据”）；
不可重复读：同一事务内，多次读取同一行数据，结果值不一致（如 A 第一次读张三余额 100，B 修改为 200 并提交，A 再次读变为 200）；
幻读：同一事务内，多次执行相同查询，结果行数不一致（如 A 查询余额 < 1000 的账户有 1 个，B 插入 1 个余额 500 的账户并提交，A 再次查变为 2 个）。

4.3 四个隔离级别详解（从低到高）

4.3.1 读未提交（Read Uncommitted）

特点：允许读取其他事务未提交的修改；
并发问题：存在脏读、不可重复读、幻读；
效率：最高（无锁）；
场景：几乎无实际用途（仅用于实验）。

4.3.2 读已提交（Read Committed）

特点：仅允许读取其他事务已提交的修改；
并发问题：解决脏读，存在不可重复读、幻读；
效率：较高；
场景：多数数据库默认级别（如 Oracle），适合对一致性要求不高的场景（如查看商品列表）。

4.3.3 可重复读（Repeatable Read，MySQL 默认）

特点：同一事务内，多次读取同一数据的结果一致；
并发问题：解决脏读、不可重复读，MySQL 通过 Next-Key 锁解决幻读（其他数据库可能仍有幻读）；
效率：中等；
场景：MySQL 默认级别，适合对一致性要求较高的场景（如订单计算）。

4.3.4 串行化（Serializable）

特点：强制事务串行执行（一个执行完再执行下一个）；
并发问题：解决所有问题；
效率：最低（加表级锁，并发阻塞严重）；
场景：仅用于一致性要求极高、并发极低的场景（如财务对账）。

4.4 隔离级别的查看与设置

4.4.1 查看隔离级别的 SQL 代码

-- 1. 查看当前会话隔离级别（常用）
select @@tx_isolation;-- 2. 查看全局隔离级别（影响新会话，不影响当前）
select @@global.tx_isolation;

4.4.2 设置隔离级别的 SQL 代码

set session transaction isolation level 级别;
set global transaction isolation level 级别;

-- 1. 设置当前会话隔离级别（仅当前客户端有效）
set session transaction isolation level read committed;-- 2. 设置全局隔离级别（新客户端生效，需重启客户端）
set global transaction isolation level repeatable read;

4.5 隔离级别与并发问题的对应关系（面试总结表）

隔离级别	脏读	不可重复读	幻读	效率	MySQL 默认
读未提交（Read Uncommitted）	√	√	√	最高	⨉
读已提交（Read Committed）	⨉	√	√	较高	⨉
可重复读（Repeatable Read）	⨉	⨉	⨉	中等	√
串行化（Serializable）	⨉	⨉	⨉	最低	⨉

5. C++ 面试 / 笔试事务高频题与解答思路

C++ 后端开发中，事务考点多围绕 “概念理解”“代码实操”“场景选择”，以下为典型题目及解答。

5.1 基础概念题：请解释 MySQL 事务的 ACID 属性

解答思路：按 “原子性→一致性→隔离性→持久性” 顺序，每条属性用 “定义 + 例子” 说明（如原子性用转账，持久性用提交后崩溃不丢失数据），避免仅背名词。

5.2 差异对比题：InnoDB 和 MyISAM 引擎在事务支持上的区别

解答思路：从 “事务支持、锁粒度、外键、崩溃恢复”4 个维度对比（见 2.1.2 表格），重点强调 “InnoDB 支持事务，MyISAM 不支持”，这是核心差异。

5.3 实操代码题：用事务实现 “张三给李四转 100 元” 的功能

需求：确保转账原子性（要么张三扣 100 且李四加 100，要么都不操作）；

解答代码（笔试必写完整流程）：

-- 1. 开启事务
begin;-- 2. 执行转账操作
update account set blance=blance-100 where name='张三';  
update account set blance=blance+100 where name='李四';  -- 3. 提交事务（若两步均成功）
commit;-- 4. 异常处理（若任意一步失败，执行回滚）
-- rollback;

关键说明：若 “张三余额不足” 导致第一条update失败，或 “李四账号不存在” 导致第二条失败，需执行rollback，避免数据不一致。

5.4 选择分析题：某电商订单系统，应选择哪个事务隔离级别？为什么？

解答思路：选择 “可重复读（MySQL 默认）”，
理由：
1. 订单计算需 “同一事务内多次读同一数据一致”（如计算订单总金额时，商品价格不会中途变化），避免不可重复读；
2. MySQL 的可重复读已解决幻读，无需选串行化；
3. 读已提交存在不可重复读，可能导致订单金额计算错误，不符合业务需求。