第 17 页：先看”出问题”的样子#

1
@Autowired
2
private EmpMapper empMapper;
3
@Autowired
4
private EmpExprMapper empExprMapper;
5

6
@Override
7
public void save(Emp emp) {
8
    //1.保存员工基本信息
9
    emp.setCreateTime(LocalDateTime.now());
10
    emp.setUpdateTime(LocalDateTime.now());
11
    empMapper.insert(emp);
12

13
    int i = 1/0;   // ← PPT 在这里人为制造一个异常（算数异常）
14

15
    //2. 保存员工的工作经历信息 - 批量
16
    Integer empId = emp.getId();
17
    List<EmpExpr> exprList = emp.getExprList();
18
    if(!CollectionUtils.isEmpty(exprList)){
19
        exprList.forEach(empExpr -> empExpr.setEmpId(empId));
20
        empExprMapper.insertBatch(exprList);
21
    }
22
}

PPT 在那张图下面写着结论，正是69 篇结尾那个问题：

保存员工信息成功了，保存工作经历信息失败了，就会造成数据库数据的不完整、不一致。

第 18 页：把这两步包进”事务”#

第 18 页在本页上叠了一层动画，图上出现三个词：

1
事务  →  开启事务  →  提交 / 回滚事务

意思就是：这两次插入要放进一个事务里——“开启事务”包住整段逻辑，全成功就”提交”，中途出错就”回滚”，让两条 SQL 同生共死。

（这就是69 篇里”无事务”对照实验的反面：本机实测把 @Transactional 去掉后，emp 里有员工、emp_expr 里 0 条——数据就是不一致的。）

第 19 页：不用自己写 SQL，交给 Spring#

第 19 页又叠了一层动画，出现”Spring事务管理”——如果在 Java 代码里真的去写 start transaction / commit / rollback（比如用 JDBC 的 Connection 对象手动开关），业务代码会被事务样板代码淹没。Spring 提供了声明式的做法：一句话注解就够。

开启事务日志，看见 Spring 到底做了什么#

事务是”看不见的”，PPT 顺带给了一段 application.yml 配置——把 Spring 事务管理器的日志级别调成 debug：

1
# 配置日志信息,查看spring事务管理的底层日志
2
logging:
3
  level:
4
    org.springframework.jdbc.support.JdbcTransactionManager: debug

这条配置本身就是63 篇讲的”配置文件里调日志级别”：JdbcTransactionManager 是 Spring 管 JDBC 事务的组件，把它设成 debug 之后，一次请求里”开事务 → 干活的 SQL → 提交 / 回滚”的全过程都会打在控制台上（下面实测部分就能看到）。

一、知识回顾（读完直接做下面的实践题）#

1. 事务的概念：一组操作的集合，是一个不可分割的工作单位——这些操作要么同时成功，要么同时失败
2. 为什么新增员工需要事务：要向 emp 和 emp_expr 两张表写入，中间失败会留下”有员工、没经历”的数据，造成数据的不完整/不一致
3. MySQL 的默认行为：默认自动提交——执行一条 DML 语句，MySQL 就立即隐式提交事务；所以两条 insert 是两个独立事务，第一条成功就挽不回了
4. SQL 控制事务三步：start transaction;（或 begin;）开启事务 → commit; 提交（全部成功）→ rollback; 回滚（只要有一项失败）
5. Spring 事务管理注解：@Transactional——方法执行前开启事务，成功执行完提交事务，出现异常回滚事务
6. @Transactional 的位置：方法上、类上、接口上；推荐加在业务（Service）层的方法上（一个方法 = 一个业务操作，边界最清晰）
7. 开启事务日志的配置：logging.level.org.springframework.jdbc.support.JdbcTransactionManager: debug——配好后能在控制台看到事务的创建、提交/回滚
8. 本机实测（正常）：响应 {"code":1,"msg":"success","data":null}；日志里有 Creating new transaction with name [com.itheima.service.impl.EmpServiceImpl.save]、Switching JDBC Connection … to manual commit、Initiating transaction commit
9. 本机实测（回滚）：在 insert 后加 int i = 1/0; → HTTP 500，日志 Initiating transaction rollback + Rolling back JDBC transaction，再查库 emp、emp_expr 都是 0 条
10. ACID 四大特性：原子性 Atomicity（不可分割的最小单元，要么全部成功要么全部失败）、一致性 Consistency（事务完成时所有数据保持一致状态）、隔离性 Isolation（不受外部并发操作影响的独立环境）、持久性 Durability（提交或回滚后对数据的改变是永久的）

二、裸写题#

• 2-1 用 SQL 手动控制一次”新增员工”的事务 需求：在客户端里模拟”新增员工”这件事——先插一条员工基本信息，再插这个员工的两条工作经历。要求这两步作为一个整体：两步都执行成功才让数据真正生效；请你故意让第二步失败（比如把表名写错、或者中途执行一条报错的语句），观察第一步的数据还在不在，再用合适的方式把这次操作撤销掉。 （练习文件 test_70_MySQL事务.sql 的题目2-1 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：在整组操作前面加”开启事务”，结尾根据成败挑”提交”或”回滚”；对照实验是”开事务”与”不开事务”各来一次 二级 · 方法：start transaction;（或 begin;）；成功用 commit;、失败用 rollback;；不顺手的表可以直接 select * from emp where username = '...'; 验证 三级 · 骨架：

  1
  -- 开启事务
  2
  ____;
  3
  insert into emp(username, name, ...) values ('事务练习', '事务练习', ...);
  4
  -- （故意报错的一句，比如表名写错）
  5
  -- 提交 / 回滚
  6
  ____;

  参考答案（做完再点开）

  1
  -- ===== 实验一：不开事务（默认自动提交）=====
  2
  insert into emp(username, name, gender, phone, job, salary, image, entry_date, dept_id, create_time, update_time)
  3
  values ('tx-test1', '事务测试一', 1, '13100000001', 1, 5000, '1.jpg', '2024-01-01', 1, now(), now());
  4
  -- 假设紧接着的"插工作经历"失败（表名故意写错）
  5
  insert into emp_expr_wrong(emp_id, begin, end, company, job) values (...);   -- 报错：表不存在
  6
  -- 结果：第一条已经落库了（自动提交），数据不一致
  7
  
  8
  -- ===== 实验二：开启事务 =====
  9
  start transaction;                  -- 也可以写 begin;
  10
  insert into emp(username, name, gender, phone, job, salary, image, entry_date, dept_id, create_time, update_time)
  11
  values ('tx-test2', '事务测试二', 1, '13100000002', 1, 5000, '1.jpg', '2024-01-01', 1, now(), now());
  12
  insert into emp_expr(emp_id, begin, end, company, job)
  13
  values (last_insert_id(),'2019-01-01','2020-01-01','百度','开发');          -- 也可以先查出 id 再写死
  14
  commit;                             -- 两条都成功 → 提交；只要有一项失败就写 rollback;

  自查：① 第一个实验里，报错之后 select * from emp where username = 'tx-test1'; 能查到——自动提交把第一条永久写进去了；② 第二个实验里，如果中途 rollback;，两条 SQL 的效果全部消失（哪怕第一条已经执行过，日志显示过 1 row affected）；③ 想清理实验数据用 delete from emp where username in ('tx-test1','tx-test2');（emp_expr 里对应的记录也一并删掉）。

• 2-2 让”保存员工”这件事由 Spring 统一管事务 需求：业务层的 save 方法里要执行”保存基本信息”和”批量保存工作经历”两次数据库操作。要求：不用在代码里手写任何开启/提交/回滚语句，只要在方法上加一个东西，就能让这两次操作成为一个事务——方法顺利执行完就提交，中途抛异常就整体回滚。另外，为了能看到事务到底有没有在工作，请打开相关的底层日志（日志级别配在配置文件里）。 （练习文件 test_70_事务管理.java 的题目2-2 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：Spring 提供了”声明式事务”——一个注解贴在业务层方法上；日志则是把 Spring 事务管理器的级别调成 debug 二级 · 方法：方法上加 @Transactional（来自 org.springframework.transaction.annotation）；yml 里写 logging.level.org.springframework.jdbc.support.JdbcTransactionManager: debug 三级 · 骨架：@____ public void save(Emp emp) { … }；yml 里 logging: → level: → org.springframework.jdbc.support.____: debug

  参考答案（做完再点开）

  1
  @Transactional                       // 方法执行前开启事务，成功提交，异常回滚
  2
  @Override
  3
  public void save(Emp emp) {
  4
      //1. 保存员工基本信息
  5
      emp.setCreateTime(LocalDateTime.now());
  6
      emp.setUpdateTime(LocalDateTime.now());
  7
      empMapper.insert(emp);
  8
  
  9
      //2. 保存员工的工作经历信息 - 批量
  10
      List<EmpExpr> exprList = emp.getExprList();
  11
      if(!CollectionUtils.isEmpty(exprList)){
  12
          exprList.forEach(empExpr -> empExpr.setEmpId(emp.getId()));
  13
          empExprMapper.insertBatch(exprList);
  14
      }
  15
  }

  显示更多显示更少

  1
  # 配置日志信息,查看spring事务管理的底层日志
  2
  logging:
  3
    level:
  4
      org.springframework.jdbc.support.JdbcTransactionManager: debug

  自查：① 注解是 org.springframework.transaction.annotation.Transactional，别导错包；② 只加注解、不改代码——start transaction/commit/rollback 一句都不用写，Spring 用代理在方法前后替你做了；③ 配好日志后，一次成功请求里能依次看到 Creating new transaction … [EmpServiceImpl.save]、Switching JDBC Connection … to manual commit、Initiating transaction commit（本机实测）。

• 2-3 把”为什么要事务”和四大特性讲清楚 需求：有人问你——① 为什么”保存员工信息成功了、保存工作经历失败了”这件事不能忍？② MySQL 不是有事务吗，为什么代码里还会出现这种不一致？③ 事务的四大特性分别是什么、各自解决了什么问题？请写一段话（可以配例子）回答清楚，并用”新增员工”这个案例把四条特性各举一次。 （练习文件 test_70_事务管理.java 的题目2-3 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：从”业务上这是一件事、数据库眼里是两条语句”的落差说起；四大特性按 原子性 → 一致性 → 隔离性 → 持久性 的顺序各配一句案例 二级 · 方法：关键词——不可分割的工作单位、要么同时成功要么同时失败、数据的不完整/不一致、默认自动提交、commit/rollback；四大特性的英文名是 Atomicity / Consistency / Isolation / Durability 三级 · 骨架：① 因为”新增员工”是____，两次写入必须____；② MySQL 默认____，两条 DML 是____，所以需要显式地____；③ 原子性=、一致性=、隔离性=、持久性=

  参考答案（做完再点开）

  ① “新增员工”在业务上是一个操作：员工和他的工作经历必须一起存在。基本信息成功、经历失败，数据库就留下一个没有工作经历的残缺员工——数据的完整性（该有的没有）和一致性（两张表对不上）都被破坏，用户看到的结果和实际发生的事不一致，所以不能忍。 ② MySQL 默认是自动提交的（执行一条 DML 就立即隐式提交），所以在没有显式开启事务时，两句 insert 是两个互相独立的小事务：第一句一提交就永久生效，第二句失败也撤不回第一句。要避免它，就得把这两句”包成一个事务”——SQL 层用 start transaction + commit/rollback，Spring 里用 @Transactional。 ③ 四大特性（ACID）：

  • 原子性 Atomicity——事务是不可分割的最小单元，要么全部成功、要么全部失败。案例：1/0 抛出后 emp 和 emp_expr 的插入都没了（本机实测 0 条）；
  • 一致性 Consistency——事务完成时所有数据保持一致状态。案例：不允许出现”员工在、经历不在”的中间状态，两张表的关联数据保持完整；
  • 隔离性 Isolation——保证事务在不受外部并发操作影响的独立环境里运行。案例：两个人同时新增员工，各自的事务互不干扰，谁也看不到对方未提交的中间结果；
  • 持久性 Durability——事务一旦提交或回滚，它对数据库数据的改变就是永久的。案例：commit 之后（或回滚之后）重启数据库，emp 里的 id=38 这条还在。

三、综合题#

• 3-1 给”新增员工”加上事务管理，并用 1/0 做一次回滚实证 这一题把本节从头到脚走一遍，重点在”用日志和数据库把结论证明出来”。

  1. 业务层的保存方法加 @Transactional（保持两次插入不动的逻辑），配置文件里打开事务管理的 debug 日志；
  2. 启动工程，发一次正常的新增员工请求（带两段工作经历），把响应 JSON 抄下来；
  3. 从控制台日志里找出三行关键日志：创建事务（方法名）、把连接切成手动提交、事务提交——分别抄下来；
  4. 去客户端查库，确认 emp 有新记录、emp_expr 两条的 emp_id 都等于新员工 id；
  5. 做回滚实验：在”保存基本信息”之后插入一行人为制造异常（int i = 1 / 0;），重新构建启动，再发一次请求（换个用户名）；
  6. 记录这次的状态码、日志里的回滚两行，并查库确认 emp 和 emp_expr 这两条数据都不在了；
  7. 收尾回答下面的两个问题。

  （练习文件 test_70_事务管理.java 的”综合题”一段里按这 7 步给了写作区。）

  回答：① 为什么说这次回滚证明了”原子性”？② 如果把 @Transactional 去掉再做第 5 步，数据库里会留下什么？（先猜，再动手验证）

  涉及知识点

  知识点	在这里的应用
  事务概念与自动提交（PPT 14）	第 5、6 步——不开事务时两句 insert 各自提交
  SQL 三步控制（PPT 15～16）	第 5、6 步——start transaction/commit/rollback 与 Spring 的对应关系
  @Transactional（PPT 21～22）	第 1、3 步——加注解 + 从日志里看创建/提交事务
  事务日志配置（PPT 21）	第 3、6 步——JdbcTransactionManager 的 debug 日志
  ACID 四大特性（PPT 28）	第 7 步——原子性/一致性/隔离性/持久性各对上一个现象
  数据不一致问题（PPT 17）	第 5、6 步——1/0 是课堂上专门用来制造失败的开关

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先看清楚”正常一次”的日志长什么样，再用 1/0 把”提交”换成”回滚”，两段日志一对比，结论就出来了 二级 · 方法：@Transactional 贴在 save 上；yml 里把 org.springframework.jdbc.support.JdbcTransactionManager 设为 debug；查库用 select * from emp where username = '...' 与 select * from emp_expr where emp_id = ... 三级 · 骨架：① @____ @Override public void save(Emp emp){ … }；② 请求 POST http://localhost:8080/____；③ 三行日志的关键词：Creating new transaction / to manual commit / Initiating transaction ____；⑤ 异常那行：int i = ____;；⑥ 回滚两行：Initiating transaction ____ 与 ____ back JDBC transaction

  参考答案（做完再点开）

  1. 业务层加注解即可（见 2-2 的答案），yml 配置也见 2-2。
  2. 本机实测响应：{"code":1,"msg":"success","data":null}。
  3. 本机实测三行关键日志（摘录）：

     1
     DEBUG o.s.jdbc.support.JdbcTransactionManager - Creating new transaction with name
     2
           [com.itheima.service.impl.EmpServiceImpl.save]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT,-java.lang.Exception
     3
     DEBUG o.s.jdbc.support.JdbcTransactionManager - Switching JDBC Connection [HikariProxyConnection@…] to manual commit
     4
     DEBUG o.s.jdbc.support.JdbcTransactionManager - Initiating transaction commit

     含义：进方法前建事务（名字是”类名.方法名”）、把自动提交换成手动提交（事务开始接管）、方法正常结束 → 提交。
  4. 本机实测查库：emp 新记录 id = 38，emp_expr 2 条，emp_id 都是 38（主键返回 + 批量插入都正常）。
  5. 异常用例：empMapper.insert(emp); 之后加 int i = 1 / 0;，重新构建启动，换一个 username 再发一次。
  6. 本机实测：HTTP 500；日志出现

     1
     DEBUG o.s.jdbc.support.JdbcTransactionManager - Initiating transaction rollback
     2
     DEBUG o.s.jdbc.support.JdbcTransactionManager - Rolling back JDBC transaction on Connection [HikariProxyConnection@…]

     查库：emp 里那条（testuser02）0 条、emp_expr 里对应记录 0 条——注意日志中明明出现过 <== Updates: 1，最终却没留下数据，这正是”回滚”。
  7. 两个回答： ① 原子性的定义是”事务是不可分割的最小单元，要么全部成功、要么全部失败”。这次两个插入没能一起成功（第二个根本没执行），于是已经执行过的那个也被撤销——整体要么全有、要么全无，从数据库里看就是”什么都没发生”，与原子性的定义完全对上。 ② 去掉 @Transactional 后再做第 5 步，会看到数据不一致：emp 表里留下了新员工，emp_expr 表里一条都没有（本机实测过这个反面场景）——因为这时的两句 insert 是两个各自提交的独立事务，第一句早就生效了。