sql中无真正事务嵌套，仅通过savepoint实现局部回滚；savepoint不开启新事务，只标记可回滚位置，共享事务id与锁范围，commit提交全部更改并清除所有savepoint。
SQL 中没有真正意义上的“事务嵌套”，所谓嵌套只是通过 Savepoint（保存点） 实现的局部回滚能力。外层事务未提交前，所有操作都在同一事务上下文中；Savepoint 不开启新事务，只标记可回滚的位置。
Savepoint 的基本用法
在事务中设置一个命名的保存点，后续可选择性回滚到该点，而不影响该点之前的操作：
- SAVEPOINT savepoint_name：创建保存点
- ROLLBACK TO SAVEPOINT savepoint_name：回滚到指定保存点（保留该点之前的操作）
- RELEASE SAVEPOINT savepoint_name：删除保存点（不释放锁，也不影响数据）
示例：
START TRANSACTION; INSERT INTO orders VALUES (101, 'Alice', '2024-04-01'); SAVEPOINT after_first_order; <p>INSERT INTO orders VALUES (102, 'Bob', '2024-04-02'); SAVEPOINT after_second_order;</p><p>INSERT INTO orders VALUES (103, 'Charlie', '2024-04-03'); -- 假设此处出错 ROLLBACK TO SAVEPOINT after_second_order; -- 撤销第三条，保留前两条</p><p>COMMIT; -- 最终提交前两条记录Savepoint 与事务边界的区别
理解 Savepoint 不等于子事务，是避免逻辑错误的关键：
- 一个事务内可建多个 Savepoint，但它们共享同一事务 ID 和锁范围
- 执行 COMMIT 会提交全部更改，并自动清除所有 Savepoint
- 执行 ROLLBACK（无 TO 子句）会回滚整个事务，所有 Savepoint 失效
- 不同数据库对 Savepoint 的命名规则略有差异（如 postgresql 区分大小写，mysql 不区分）
常见使用场景
Savepoint 特别适合需要“部分容错”的业务流程：
- 批量插入中的单条失败处理：逐条插入并设 Savepoint，某条失败时回滚到上一 Savepoint，继续下一条
- 条件分支逻辑：在 if 分支中设 Savepoint，根据结果决定是否保留该分支的修改
- 存储过程中模拟可回滚的子操作：例如更新用户信息时，先改基础字段，再尝试更新扩展字段，后者失败不影响前者
注意事项与兼容性
并非所有数据库引擎都完全支持 Savepoint，使用前需确认：
- MySQL：InnoDB 支持完整 Savepoint 功能；MyISAM 不支持事务，故也不支持
- PostgreSQL：支持且允许重复定义同名 Savepoint（后定义覆盖前定义）
- SQL Server：使用 SAVE TRANSACTION，行为类似，但不支持 RELEASE
- SQLite：支持，但 Savepoint 名称不能包含空格或特殊字符
- 避免在循环中无限制创建 Savepoint，可能引发资源开销或名称冲突