mysql不支持嵌套事务，但可用savepoint在显式事务中设标记点实现局部回滚；须满足innodb引擎、autocommit=0、begin/start transaction开启事务三前提，同名保存点静默覆盖，rollback to不释放锁，ddl会隐式提交致保存点失效。

MySQL 不支持真正的嵌套事务，但可以用 SAVEPOINT 实现逻辑上的“局部回滚”——它不是开启子事务，而是在当前事务内设一个可回退的标记点，只撤销该点之后的修改。

必须满足的前提条件

SAVEPOINT 有效运行依赖三个硬性前提：

• 使用支持事务的存储引擎（如 InnoDB；MyISAM 完全忽略 SAVEPOINT）
• 会话中 autocommit = 0（默认是 1，需显式关闭）
• 必须在 BEGIN 或 START TRANSACTION 开启的显式事务中使用

正确设置与回滚操作流程

典型四步不可省略：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 开启事务：START TRANSACTION;
• 执行前置操作（希望保留的部分，如写日志、插入主记录）
• 设保存点：SAVEPOINT sp_before_risky_step;（命名建议带业务含义，避免复用）
• 执行风险操作（如批量更新、关联插入），出错时执行：ROLLBACK TO SAVEPOINT sp_before_risky_step;

注意：ROLLBACK TO SAVEPOINT 后事务仍活跃，可继续执行其他语句或再次设点；但该保存点之后创建的其他保存点会被自动清除。

关键行为与常见陷阱

理解这些才能避免误用：

• 同名 SAVEPOINT 会静默覆盖前一个——第二次 SAVEPOINT sp1 执行后，第一次的回滚位置就丢失了
• ROLLBACK TO SAVEPOINT 不释放行锁（尤其是新插入行的锁），其他事务可能被阻塞，直到整个事务结束
• DDL 操作（如 ALTER TABLE、DROP TABLE）会隐式提交，导致所有已设保存点立即失效
• 连接池场景下，若上个请求未 COMMIT 或 ROLLBACK，当前请求一设保存点就可能报 “transaction not active”

清理与收尾建议

虽非强制，但推荐主动管理：

• 确认不再需要某保存点时，用 RELEASE SAVEPOINT sp_name; 显式释放（不改数据，仅删标记）
• 事务最终必须以 COMMIT 或全量 ROLLBACK 结束——此时所有保存点自动清除
• 不要依赖存储过程外层设的保存点：触发器或被调函数内部设的点，退出即销毁，无法跨作用域引用