必须在调用存储过程前显式开启事务且autocommit=0，否则SAVEPOINT无效；同名保存点会静默覆盖；回滚到保存点不释放锁；SQL Server无RELEASE SAVEPOINT，MySQL支持。
必须在调用存储过程前显式开启事务，且 autocommit=0；否则 SAVEPOINT 无效，ROLLBACK TO 会直接报错或静默失效。
SAVEPOINT 在存储过程中不自动生效
很多人以为在存储过程里写 SAVEPOINT sp1 就能局部回滚，结果发现根本没用。根本原因是：SQL Server 和 MySQL 都要求 SAVEPOINT 必须处于一个活跃的、用户显式启动的事务中——而存储过程本身不会自动创建事务上下文。
- SQL Server 中，
SAVE TRANSACTION sp1只在当前连接已有未提交事务时才有效；若调用方没执行BEGIN TRANSACTION，该语句会成功但后续ROLLBACK TRANSACTION sp1报错SAVEPOINT sp1 does not exist - MySQL 同理：
SAVEPOINT sp1在autocommit=1下完全被忽略，查SELECT @@autocommit必须是0，且前面必须有BEGIN或START TRANSACTION - 即使存储过程内部写了
BEGIN TRY / CATCH或DECLARE EXIT HANDLER，也只负责捕获异常，不负责启动事务——事务边界必须由调用方控制
命名与覆盖：同名保存点会静默替换
在同一个事务中多次执行 SAVE TRANSACTION sp1（SQL Server）或 SAVEPOINT sp1（MySQL），后一次会无提示覆盖前一次。这不是 bug，是标准行为。
- 回滚时
ROLLBACK TO sp1总是回到最近一次设置的位置，旧的 undo 状态已丢失 - 建议用带业务语义的名称，比如
sp_before_insert_order、sp_after_update_stock，避免复用sp1这类泛化名 - SQL Server 要求
savepoint_name不超过 32 字符、区分大小写；MySQL 对长度和大小写限制较宽松，但命名一致性仍影响可维护性
锁不会随 ROLLBACK TO SAVEPOINT 释放
这是最容易被忽视的坑：回滚到保存点后，数据改回来了，但行锁还在。
- SQL Server 中，
ROLLBACK TRANSACTION sp1会释放该点之后获取的新锁（如新插入行的 X 锁），但**不会释放升级后的锁**（比如从 U 锁升级为 X 锁） - MySQL InnoDB 同样不释放保存点之后持有的行锁；如果你在保存点后做了
SELECT ... FOR UPDATE，哪怕回滚了，其他事务仍会被阻塞 - 验证是否真释放？查
sys.dm_tran_locks（SQL Server）或INFORMATION_SCHEMA.INNODB_TRX（MySQL），别只看 SELECT 查询结果
存储过程内设保存点需主动清理
保存点不是“子事务”，它只是事务内的标记。你设了不用，也不会报错，但可能干扰后续逻辑判断。
- SQL Server 没有
RELEASE SAVEPOINT语法，只能靠 COMMIT/ROLLBACK 全局结束来清除；但建议在确认不再需要时，用ROLLBACK TRANSACTION sp1再立刻继续执行，或干脆用不同名避免混淆 - MySQL 支持
RELEASE SAVEPOINT sp1，推荐在局部逻辑完成且确定不需回滚时显式调用，让意图清晰 - 跨存储过程调用时，内层过程设的保存点对外层不可见，退出即销毁——不能指望外层回滚到内层的保存点
真正起作用的从来不是“有没有写 SAVEPOINT”，而是“事务是否真的在运行”以及“回滚后锁还卡着谁”。每次设点前，先查 @@TRANCOUNT（SQL Server）或 SELECT @@autocommit, @@in_transaction（MySQL），比反复试错快得多。
