应将高风险子查询改写为独立语句（如select into或set @var=），并配合try...catch捕获；对空值或类型转换风险，使用isnull、case when或if exists预判；禁用set xact_abort on时需手动回滚，启用时须确保catch中检查xact_state()并处理。
子查询报错时存储过程直接中断，怎么捕获？
SQL Server 的存储过程中，子查询（比如 SELECT 子句里嵌套的 (SELECT ...) 或 WHERE col IN (SELECT ...)）一旦出错（如除零、类型转换失败、空集导致标量变量赋值失败），默认会立即终止整个存储过程，且无法被常规 TRY...CATCH 捕获——因为这类错误属于“编译期可检测”或“语句级运行时错误”，在某些执行路径下甚至不进入 CATCH 块。
真正能被 TRY...CATCH 拦住的，是语句执行阶段抛出的严重级别 11–19 的运行时错误；而子查询中常见的 Divide by zero error encountered. 或 Conversion failed when converting... 属于这一范围，但前提是它发生在独立可执行语句中，而非作为表达式的一部分被优化掉。
- 把子查询改写为显式
SELECT INTO #temp或SET @var = (SELECT ...)形式，使其成为独立语句，才能触发TRY...CATCH - 避免在
WHERE/SELECT列表中直接写高风险子查询；改用LEFT JOIN+ISNULL()或CASE WHEN防御性包裹 - 对可能为空的标量子查询，始终用
ISNULL((SELECT TOP 1 ...), 0)或先IF EXISTS(...)判断
嵌套事务中子查询失败，外层事务会回滚吗？
SQL Server 不支持真正的嵌套事务。所谓 SAVE TRANSACTION 只是设置回滚点，ROLLBACK TO savepoint 可局部回退，但一旦执行了 ROLLBACK TRANSACTION（无目标点），就会回滚到最外层 BEGIN TRANSACTION，且所有保存点失效。
关键点在于：子查询异常是否引发事务状态变更？答案是——会。只要错误未被捕获，事务会进入不可提交状态（XACT_STATE() = -1），此时任何后续 COMMIT 都失败，必须 ROLLBACK。
- 在
TRY块内执行子查询前，先用IF @@TRANCOUNT > 0 AND XACT_STATE() = 1确认事务可提交 - 不要依赖
SAVE TRANSACTION sp1来“隔离”子查询失败的影响；它防不住XACT_STATE() = -1的情况 - 若需逻辑隔离，改用独立存储过程 +
EXEC ...调用，并在调用侧处理错误返回值
用 RETURN 值 + 错误号判断比 TRY CATCH 更可靠？
对频繁调用、稳定性要求高的子过程，仅靠 TRY...CATCH 不够。SQL Server 在某些上下文（如函数内、触发器中、或被 SET XACT_ABORT ON 影响时）会跳过 CATCH，直接终止。此时更稳的方式是：把子查询逻辑拆进独立存储过程，用 RETURN @err 显式反馈，并在外层检查 @@ERROR 或输出参数。
- 子过程结尾统一写：
RETURN ISNULL(@@ERROR, 0)，非零即失败 - 调用侧写：
EXEC @ret = usp_GetValue @id, @out_val OUTPUT; IF @ret 0 GOTO ErrorHandler - 避免在子过程中做
RAISERROR后还继续执行——错误已抛出，后续逻辑可能污染状态
SET XACT_ABORT 对子查询异常处理的影响
SET XACT_ABORT ON 是双刃剑：它让大多数运行时错误自动回滚整个事务（包括隐式事务），避免悬挂事务，但也会让原本可被 CATCH 捕获的错误直接终止批处理，跳过 CATCH 块。
典型表现：开启后，子查询中的 CONVERT 失败会直接退出，TRY...CATCH 完全不执行；关闭后，同一错误可被捕获，但需手动 ROLLBACK，否则事务挂起。
- 线上环境建议
SET XACT_ABORT ON，但必须配合TRY...CATCH且每个CATCH内做IF XACT_STATE() 0 ROLLBACK - 开发调试阶段可临时关掉，方便定位哪条语句出问题
- 永远不要假设
@@TRANCOUNT在CATCH中一定 > 0——先查XACT_STATE()
