SQL Server和MySQL均不支持真正嵌套事务，子过程内执行BEGIN TRANSACTION或START TRANSACTION会破坏外层事务：SQL Server因@@TRANCOUNT失配报错Msg 266，MySQL则隐式提交前序操作；唯一安全的局部回滚手段是SAVE TRANSACTION（SQL Server）或SAVEPOINT（MySQL），且须配合异常处理器并由最外层统一控制事务边界。
SQL Server 和 MySQL 都不支持真正意义上的嵌套事务，所谓“子过程参与外层事务”只靠共享同一事务上下文实现——子过程不能自己 BEGIN TRANSACTION，也不能自己 COMMIT 或无条件 ROLLBACK，否则必然破坏 @@TRANCOUNT 平衡或触发隐式提交。
为什么子过程里写 BEGIN TRANSACTION 会报错 Msg 266
错误本质是事务计数失配：@@TRANCOUNT 在外层已为 1，子过程再执行 BEGIN TRANSACTION 会变成 2；若子过程内部又 ROLLBACK，@@TRANCOUNT 直接归零；外层接着 COMMIT 时发现计数为 0，就抛出 “Transaction count after EXECUTE indicates a mismatch”。
- 子过程绝不能裸写
BEGIN TRANSACTION/COMMIT TRANSACTION/ROLLBACK TRANSACTION - 子过程若需局部回滚能力，必须用
SAVE TRANSACTION savepoint_name（SQL Server）或SAVEPOINT sp_name（MySQL），且仅在已有事务中调用 - 子过程应通过
RETURN值或OUTPUT参数通知调用方执行结果，由最外层统一决定是否回滚
SQL Server 中安全调用子过程的模板写法
核心是判断当前是否已在事务中，并据此选择设保存点还是开启新事务：
- 开头先查
@@TRANCOUNT：若 > 0，执行SAVE TRANSACTION proc_sp；若 = 0，才执行BEGIN TRANSACTION - 所有业务逻辑后，检查
@@ERROR或用TRY/CATCH，出错则ROLLBACK TRANSACTION proc_sp（不是ROLLBACK） - 成功时：若原
@@TRANCOUNT = 0，则COMMIT TRANSACTION；否则不做提交，交由上层处理 - 务必启用
SET XACT_ABORT ON，避免部分语句失败后事务卡在不确定状态
MySQL 存储过程中调用子过程的事务边界陷阱
MySQL 更激进：子过程里任何 START TRANSACTION 或 COMMIT 都会隐式提交当前事务，导致前面所有未提交操作落地——这和“嵌套”完全相反。
- 子过程体中禁止出现
START TRANSACTION、COMMIT、ROLLBACK -
SAVEPOINT必须配合DECLARE EXIT HANDLER FOR SQLEXCEPTION，且 handler 声明必须在SAVEPOINT之前，否则异常触发时找不到保存点，报错ERROR 1305 (42000): SAVEPOINT does not exist - 保存点名必须是字面量，不能是变量（如
@sp_name），动态命名需用PREPARE + EXECUTE，但有注入风险，慎用 - 子过程返回值只能靠
OUT参数或临时表，函数无法承担事务控制逻辑
跨数据库通用原则：事务边界永远交给最外层
真正容易被忽略的是设计层面的惯性——开发者总想让每个子过程“自洽”，结果反而制造出不可预测的锁持有时间、死锁窗口和错误传播盲区。
- 应用层或调度存储过程才是事务起点，子过程只做原子操作 + 异常反馈
- 多个子过程按固定顺序调用（如
usp_charge → usp_credit → usp_log），并在注释中标明锁序：-- LOCK ORDER: accounts → transactions → audit_log - 批量操作必须分批（如
TOP (500)循环），每批后显式COMMIT，避免单事务锁住数万行 - 所有被调用的子过程 WHERE 条件字段必须有索引，且类型严格匹配（INT 字段别传字符串），否则全表扫描会把行锁升级成页锁甚至表锁
