能，但仅限当前事务内，且必须配合rollback transaction指定保存点名使用；save transaction只是设回退锚点，非快照，不支持跨批、跨过程或回滚已提交修改。
SAVE TRANSACTION 能否真正回滚到保存点
能，但仅限当前事务内，且必须配合 ROLLBACK TRANSACTION 指定保存点名使用。SQL Server 不支持跨批、跨存储过程或嵌套事务中“恢复”已提交的修改——SAVE TRANSACTION 只是设一个回退锚点，不是快照或备份。
常见错误现象：ROLLBACK TRANSACTION 未带保存点名，结果整个事务回滚；或在 COMMIT TRANSACTION 后还试图回滚到该保存点，此时报错 The SAVE TRANSACTION statement is not allowed in a distributed transaction 或直接提示“找不到保存点”。
- 保存点名必须是合法标识符（不能含空格、特殊字符），建议用前缀如
sp_update_user - 同一事务中可设多个保存点，后设的不影响先设的，但回滚到某点后，其后的保存点自动失效
- 若存储过程中调用其他含
SAVE TRANSACTION的过程，需确保外部事务未提前COMMIT，否则内部保存点不可达
在存储过程中正确设置和回滚到保存点
关键在于事务生命周期管理：存储过程本身不开启事务时，SAVE TRANSACTION 依赖外部事务上下文；若过程内显式 BEGIN TRANSACTION，则保存点只对该事务有效。
典型场景：批量更新用户状态，其中某条记录校验失败，需跳过它但保留前面成功的更新。
CREATE PROCEDURE UpdateUserStatus
@UserID INT,
@NewStatus VARCHAR(20)
AS
BEGIN
-- 假设调用方已 BEGIN TRANSACTION，此处不重复开事务
SAVE TRANSACTION sp_update_user;
<pre class="brush:php;toolbar:false;">BEGIN TRY
UPDATE Users SET Status = @NewStatus WHERE ID = @UserID;
IF @@ROWCOUNT = 0
RAISERROR('User not found', 16, 1);
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION sp_update_user; -- 回滚到保存点，不破坏外层事务
RETURN;
END CATCHEND
- 不推荐在存储过程里无条件
BEGIN TRANSACTION，容易与调用方事务冲突 -
SAVE TRANSACTION必须在TRY块之前，否则异常发生时保存点可能未建立 - 回滚后应显式
RETURN，避免后续逻辑误执行
为什么 ROLLBACK TO SAVEPOINT 在 SQL Server 中写法不同
MySQL/PostgreSQL 用 ROLLBACK TO SAVEPOINT sp_name，而 SQL Server 必须写成 ROLLBACK TRANSACTION sp_name。混淆写法会导致语法错误：Incorrect syntax near 'TO'。
更隐蔽的问题是：SQL Server 不允许在保存点之后执行某些语句再回滚，例如 CREATE TABLE 或 DROP INDEX —— 这些隐式提交操作会让保存点失效，后续 ROLLBACK TRANSACTION sp_name 报错 The current transaction cannot be committed and cannot support operations that write to the log file。
- 只对 DML（
INSERT/UPDATE/DELETE）和部分 DDL（如ALTER TABLE ... SWITCH）安全 - 避免在保存点范围内执行
TRUNCATE TABLE，它虽不记日志但会重置标识列，且无法被保存点保护 - 测试时务必在真实事务上下文中验证，单独执行存储过程（无外层事务）会导致
SAVE TRANSACTION失效并报错The SAVE TRANSACTION statement is not allowed outside of a transaction
嵌套存储过程中的保存点传递问题
SQL Server 的保存点作用域是当前事务，不是当前作用域。也就是说，父过程设的保存点，子过程可以回滚；但子过程设的保存点，父过程也能回滚——只要都在同一事务中。
风险点在于：子过程若自行 COMMIT 或 ROLLBACK，会终结整个事务，父过程的保存点立即作废。所以协作前提必须是“全链路不自主提交”。
- 所有参与过程应约定：事务由最外层调用者控制，内部只设保存点、抛异常、让调用者决定
COMMIT或ROLLBACK - 可用
XACT_STATE()判断当前事务是否可提交（值为 1），避免在不可提交状态下强行COMMIT - 调试时用
SELECT @@TRANCOUNT, XACT_STATE()快速确认事务嵌套深度和健康状态
实际用起来最易忽略的是：保存点不是隔离机制，它不阻止并发修改。两个并行执行的过程设同名保存点，不会互相干扰，但各自回滚只影响自己那部分数据变更——名字只是标签，不是锁。
