SQL Server 中嵌套事务只是 @@TRANCOUNT 计数器递增，并非独立事务；内层 ROLLBACK 会清零计数器并终止整个事务，导致外层语句报错中止；应使用 SAVE TRANSACTION + ROLLBACK TO 或应用层独立连接实现局部回滚。
SQL Server 中 BEGIN TRAN 嵌套不等于事务隔离
嵌套事务在 SQL Server 里只是 @@TRANCOUNT 计数器加 1，不是新开一个独立事务上下文。外层事务一旦回滚，所有嵌套层级的数据修改都会被一并撤销——下层过程自己调用 COMMIT 或 ROLLBACK 不会改变这个事实。根本原因在于：SQL Server 没有真正的“子事务”概念，只有“事务计数”和“最外层提交/回滚”两个动作点。
为什么 ROLLBACK TRAN 在内层执行会导致报错
常见错误信息：The transaction ended in the trigger. The batch has been aborted.。这是因为内层存储过程执行了 ROLLBACK TRAN，把 @@TRANCOUNT 直接清零，但外层过程仍以为事务还在进行，后续语句（比如再查一次表、或执行 COMMIT）就会因事务状态不一致而中断。尤其在触发器或嵌套调用链中，这种失衡极易发生。
- 外层过程执行
BEGIN TRAN→@@TRANCOUNT = 1 - 调用内层过程，它也执行
BEGIN TRAN→@@TRANCOUNT = 2 - 内层过程执行
ROLLBACK TRAN→@@TRANCOUNT = 0，且整个事务被标记为“已结束” - 外层过程继续执行，哪怕只是一句
SELECT 1，也会触发批处理中止
想让某段逻辑“不受外层事务影响”，该用什么
不是靠嵌套事务，而是用 SAVE TRANSACTION + ROLLBACK TO，或者更彻底地——改用自治事务（仅限 Oracle）或拆出独立连接（如应用层另起一个数据库连接执行日志写入）。SQL Server 本身不支持自治事务；如果真需要审计日志不被主事务回滚掉，只能：
- 把日志写入操作移到主事务之外，比如用 Service Broker、外部队列，或由应用层异步处理
- 使用
SAVE TRANSACTION savepoint_name设保存点，内层出错时只回滚到该点，保留外层可继续提交 - 避免在数据操作型存储过程中自行
BEGIN/COMMIT/ROLLBACK，统一由最外层业务过程控制事务边界
金仓（KingbaseES）兼容版的特殊情况
如果你正从 SQL Server 迁移到 KingbaseES SQL Server 兼容版，要注意：虽然它支持 TRY...CATCH 和 SAVE TRANSACTION，但嵌套事务行为仍与 SQL Server 一致——@@TRANCOUNT 失衡问题同样存在。官方文档明确指出其事务层级和 xact_abort 行为是兼容的，这意味着你不能指望换平台就自动解决嵌套回滚混乱的问题。
TRAN 相关语句。 
