mysql不支持真正的嵌套事务，只能通过savepoint实现局部回滚；spring的nested传播机制底层依赖savepoint，并非真正嵌套事务；需确保使用innodb引擎、关闭autocommit、合理配置超时时间。
MySQL 本身不支持真正的嵌套事务
这是所有问题的起点：MySQL 的 BEGIN/COMMIT 机制不提供嵌套事务语义。所谓“嵌套”，只是应用层（如 C# 的 TransactionScope 或 Spring 的 @Transactional）模拟出来的行为，底层仍依赖单个连接上的单一事务状态。一旦你在同一连接上调用多次 connection.BeginTransaction()，MySQL 实际只认最后一个——前面的调用被忽略或静默覆盖，导致回滚/提交行为不可控。
常见错误现象包括：
System.Transactions.TransactionAbortedException: The transaction has aborted.- 子操作失败但主事务未回滚，数据部分写入
- 显式调用
innerTransaction.Commit()后，外层outerTransaction.Rollback()失效
根本原因不是代码写错，而是试图让 MySQL 做它不支持的事。
用 Savepoint 替代“子事务”是最可靠的做法
MySQL 支持 SAVEPOINT，它是在一个事务内打标记、允许局部回滚的机制，不新开事务、不切换连接、完全兼容 InnoDB。
实操建议：
- 在需要“子事务边界”的位置执行
SAVEPOINT savepoint_name - 后续出错时，用
ROLLBACK TO SAVEPOINT savepoint_name撤销该点之后的操作 - 整个事务仍由最外层的
COMMIT或ROLLBACK统一收口 - 注意：每个
SAVEPOINT名称在同一事务中必须唯一；重复定义会覆盖前一个
示例（纯 SQL）：
START TRANSACTION; INSERT INTO orders VALUES (1, 'pending'); SAVEPOINT order_inserted; <p>INSERT INTO order_items VALUES (1, 'item_a', 100); -- 若此处失败，可回退到 order_inserted 点，不影响 orders 表 ROLLBACK TO SAVEPOINT order_inserted;</p><p>COMMIT;</p>
Spring 中避免 @Transactional 嵌套传播陷阱
Spring 的 PROPAGATION_NESTED 看似支持嵌套，但它底层仍是靠 SAVEPOINT 实现（仅对 DataSourceTransactionManager 有效），并非真正开启新事务。如果配置了错误的事务管理器（如 JTA），或底层连接不支持 Savepoint（极少见），就会退化为 PROPAGATION_REQUIRED，失去局部回滚能力。
容易踩的坑：
- 误以为
@Transactional(propagation = Propagation.NESTED)能跨线程/跨连接生效 → 实际必须在同一数据库连接内 - 在非 public 方法上标注
@Transactional→ AOP 代理失效，注解被忽略 - 自身调用：serviceA.methodA() 内直接调用 this.methodB()，即使 methodB 有
@Transactional，也不会触发新代理逻辑 - rollbackFor 配置窄：比如只设
rollbackFor = Error.class，而业务抛的是Exception→ 不回滚
生产环境必须验证的三件事
嵌套事务类问题在测试库常被掩盖，因为并发低、数据少、异常路径难覆盖。上线前务必确认：
- 目标表引擎是
InnoDB（执行SHOW CREATE TABLE table_name查看ENGINE=InnoDB） - 连接池未启用 autoCommit（如 HikariCP 的
auto-commit=false；Druid 的defaultAutoCommit=false） - 事务超时时间（
@Transactional(timeout = ...)或连接池 socketTimeout）大于最长业务路径耗时，否则可能被强制中断并回滚，且不报明确事务异常
最隐蔽的问题往往不在事务代码本身，而在连接复用和超时配置——它们会让“看似成功”的事务在下游突然失败，且日志里只留下 Connection closed 或 Lock wait timeout exceeded 这类间接线索。
