在 PostgreSQL 中，如果事务执行到一半发现某条语句出错，但前面的操作希望保留，后面还能继续提交剩余部分，SAVEPOINT 就是为这种部分回滚设计的。它不会像 ROLLBACK 那样把整个事务清空，而是在事务内部划出若干个回滚点，让你可以跳回任意一个保存点继续工作。真正用好保存点，需要理解它的生命周期、回滚后哪些资源会保留、哪些语句会重新执行，否则很容易出现数据状态和预期不一致的现象。
一、SAVEPOINT 的基本语法与回滚语义
SAVEPOINT 是事务内部的一个命名回滚点。事务开启后，执行 SAVEPOINT 名字，PostgreSQL 会记录当前事务执行位置。之后如果发现需要撤销到某一处，可以用 ROLLBACK TO SAVEPOINT 名字。回滚完成后，事务不会结束，保存点也仍然存在，可以继续执行后续 SQL。如果确定后续不再需要回退到该保存点，用 RELEASE SAVEPOINT 名字 显式销毁。释放保存点不会把之前的变更单独提交，它只是删除一个回滚标记，这些变更仍受外层事务控制，最终由 COMMIT 提交或由 ROLLBACK 整体丢弃。
下面是一个标准示例，演示插入一条记录后回滚到保存点，再执行另一条更新并提交。注意第一次插入被撤销后，如果插入语句使用了序列，序列值不会因为回滚而退回，这是很多业务中容易忽略的细节。
BEGIN; SAVEPOINT sp1; INSERT INTO orders (id, amount) VALUES (1, 100); ROLLBACK TO SAVEPOINT sp1; UPDATE orders SET amount = 200 WHERE id = 1; RELEASE SAVEPOINT sp1; COMMIT;
与不带 TO 的 ROLLBACK 完全不同的是，ROLLBACK 会立即终止事务并释放所有该事务持有的锁；而 ROLLBACK TO SAVEPOINT 只让事务状态回退到保存点，顶层事务继续持有事务ID、快照和大部分锁。这个特性让保存点非常适合做“出错重试”或“部分丢弃”的场景，但也要注意，保存点回滚并不是免费的，它会留下子事务记录，长期不清理会造成额外开销。
二、保存点背后的子事务机制
在 PostgreSQL 内部，每执行一个 SAVEPOINT，就相当于开启一个嵌套的子事务。子事务拥有自己的事务ID分配、命令计数器起始值以及资源所有者。当子事务执行写操作时，会产生新的 XID，虽然这个 XID 与顶层事务同属于一个事务块，但在可见性判断和回滚处理上会单独记录状态。PostgreSQL 使用一个子事务数组记录嵌套关系，以及每个子事务的状态。
执行 ROLLBACK TO SAVEPOINT 时，存储引擎并不会回到物理时间点去撤销已经写入的堆元组和 WAL 记录，而是把这个保存点对应的子事务以及所有后续子事务标记为中止。后续的查询和索引扫描在检查元组可见性时，会发现这些变更来自已中止的子事务，从而把它们排除在结果之外。这种机制让回滚非常快，因为不需要反向扫描已经产生的 WAL 或脏页，只需要修改事务状态即可。不过，这同样意味着这些无效的元组版本并不会被立即清理，如果事务继续运行并产生更多写入，表膨胀会更明显。
子事务机制也影响着锁的行为。PostgreSQL 的锁与事务顶层绑定，部分锁虽然在保存点回滚后逻辑上不再冲突，但实际释放可能会延迟到顶层事务结束。尤其是在子事务中执行 DDL 或 LOCK TABLE 时，重锁倾向持续到 COMMIT。因此，如果一个长事务反复创建保存点并执行会加锁的语句，即使每次回滚，仍可能积累大量锁资源，甚至阻塞其他会话。理解了逻辑回滚和资源释放之间的差异，才能更好地设计保存点的使用方式。
三、部分回滚在批量处理与存储过程中的实践
批量导入或迁移数据时，最常见的问题是一条坏数据导致整个批处理失败。如果每个批次一个事务，失败后全部回滚，后续数据也得重新执行。保存点可以缩小失败范围：在容易出错的单条语句或单条记录前后设置保存点，失败后回滚到该点，记录错误并继续处理剩余数据。这在数据清洗、消息消费、定时任务中非常实用。
在 PL/pgSQL 中，BEGIN...EXCEPTION...END 块本身就会创建隐式保存点。当块内发生异常时，PL/pgSQL 自动回滚到块开始位置，然后执行异常处理分支。下面的 DO 块循环处理 staging_data 表，遇到唯一键冲突时跳过该行，而不是中断整个过程。尽管代码里没有写 SAVEPOINT，实际上引擎内部使用了子事务完成同样效果。
DO $$
DECLARE
v_id INT;
v_err_count INT := 0;
BEGIN
FOR v_id IN SELECT id FROM staging_data
LOOP
BEGIN
INSERT INTO orders (id, amount) VALUES (v_id, 100);
EXCEPTION
WHEN unique_violation THEN
v_err_count := v_err_count + 1;
END;
END LOOP;
RAISE NOTICE 'skipped % duplicate rows', v_err_count;
END;
$$;
如果错误率很低，使用异常块保存点带来的开销可以接受；但如果数据质量差、几乎每条都冲突，异常块的子事务创建和回滚会显著拖慢速度。这时可以先做批量预校验，再对少量可能出错的行用 SAVEPOINT 或异常块。显式 SAVEPOINT 则更适合在 SQL 事务中手动控制回滚边界，例如在复杂转账流程中，对扣款和入账之间的中间步骤设置保存点，失败时只撤销后半段，保留前半段已完成的校验结果。嵌套保存点可以在一个大的业务块中进一步划分粒度，但要适度，避免过度设计。
四、保存点的锁、性能与常见误用
保存点虽然好用，但每个 SAVEPOINT 都会增加子事务开销。PostgreSQL 需要为子事务分配内存、记录 WAL，顶层事务提交或回滚时也要清理所有子事务状态。如果一个事务内部建立了数万个保存点，可能会出现子事务相关的性能下降，甚至触发共享内存限制。建议保存点用完后及时 RELEASE，并且避免在紧密循环里为每行都创建保存点。通常同一事务中保存点数量控制在百级以内比较稳妥，具体还要看服务器内存和并发负载。
关于锁，有一个容易踩的坑：ROLLBACK TO SAVEPOINT 并不会像很多人直觉认为的那样立即释放该保存点之后获取的所有锁。PostgreSQL 行锁通常与顶层事务绑定，即使回滚到保存点，某些行级锁仍然保留到顶层 COMMIT 或 ROLLBACK，这会延长锁持有时间，可能引发其他会话的等待。DDL 和 LOCK 命令获取的重锁更是如此。因此，如果事务中要用保存点回滚来决定是否继续，必须考虑锁竞争，不能把保存点当作释放资源的手段。
另一个常见误用是把 SAVEPOINT 当作自动提交或独立小事务。保存点的提交实际只是释放标记，真正的原子提交仍在外层事务。还有像序列值、触发器对外部系统的调用、通知等副作用，在保存点回滚后不会撤销；序列的 nextval 值不会回退，邮件、消息等外部操作更无法撤销。打开游标后回滚到保存点，游标的位置和资源可能保持，但读取语义要谨慎。理解了这些限制，可以把保存点放在合适的抽象层，而不是所有场景都依赖它。
SAVEPOINT 是 PostgreSQL 事务模型中非常灵活的部分回滚机制。它在批量处理跳过坏数据、存储过程异常恢复、复杂业务原子性控制等场景中都有实际价值。使用时要意识到它对应的子事务开销、锁保持时间以及不可逆的副作用，才能真正发挥回滚部分而不是全部的能力。最终设计应尽量及时释放保存点，控制嵌套层数，并把资源释放和逻辑回滚区分开。
PostgreSQLSAVEPOINT事务回滚修改时间：2026-10-05 18:54:31