复杂嵌套逻辑应拆分为子存储过程，而非堆砌于单个过程中；sql server中需显式处理异常传播与事务边界，避免begin嵌套混乱，并优先使用参数化exec调用以保障安全。
复杂嵌套逻辑不该堆在单个存储过程中——拆成子过程不是“过度设计”，而是避免 IF 套 IF、BEGIN 套 BEGIN 后连自己都看不懂的唯一办法。
SQL Server 中如何安全调用嵌套存储过程
外层过程直接 EXEC 内层过程是可行的，但必须处理好错误传播和事务边界。内层过程抛出的异常默认不会自动中断外层流程，除非显式加 THROW 或用 SET XACT_ABORT ON。
- 每个子过程开头应加
SET NOCOUNT ON，否则多条SELECT会干扰客户端结果集解析 - 若外层已开启事务，内层过程不能自行
COMMIT，否则触发“事务计数不匹配”错误Msg 266 - 传参时避免用
EXEC('...')拼接字符串，容易 SQL 注入；优先用参数化EXEC proc_name @p1 = ?, @p2 = ? - 调试时可在子过程中加
RAISERROR('in subproc: %d', 0, 1, @id) WITH NOWAIT，确保日志实时刷出
MySQL 存储过程中嵌套调用的 DELIMITER 陷阱
嵌套过程本身不难，真正卡住人的是 DELIMITER 作用域混乱——尤其当外层过程定义里又 CREATE PROCEDURE 内层过程时，分号解析会提前截断。
- 外层过程体中不能直接写
CREATE PROCEDURE，否则报错ERROR 1064；必须把内层过程单独创建，再用CALL调用 - 每个
CREATE PROCEDURE前后都要配对DELIMITER //和DELIMITER ;，漏一个就会让后续所有语句失效 - MySQL 不支持过程重载，同名子过程第二次
CREATE会失败，需先DROP PROCEDURE IF EXISTS - 子过程返回值只能靠
OUT参数或临时表，不能像函数那样直接赋值给变量
什么时候该把逻辑拆进子过程，而不是用标量函数
标量函数看着干净，但用错场景反而拖慢性能——尤其涉及表访问或事务控制时。
- 需要读写多张表、执行
INSERT/UPDATE/DELETE的逻辑，必须用子过程；函数里禁止数据修改操作（SQL Server 报错Msg 443，MySQL 报错ERROR 1418） - 要捕获异常并做分支处理（比如库存不足时回滚+记录日志），只能放子过程中，函数无法
TRY...CATCH或DECLARE HANDLER - 若某段逻辑被 3 个以上主过程复用，且每次调用参数结构一致，就值得独立为子过程；否则只是增加一层 CALL 开销
- 注意：SQL Server 中子过程不能返回表值，如需返回结果集，得改用表值函数（TVF）或临时表 +
SELECT输出
PostgreSQL 中嵌套逻辑的 EXCEPTION 隔离难点
PostgreSQL 的 EXCEPTION 块只对当前 BEGIN...END 生效，嵌套调用时异常不会自动冒泡——这是最常被忽略的坑。
- 子过程里的
EXCEPTION捕获后，若没RAISE，外层过程完全感知不到错误，可能继续执行导致脏数据 - 唯一约束冲突（
SQLSTATE '23505'）必须在子过程中显式RAISE EXCEPTION并带新 SQLSTATE，否则外层无法按类型区分处理 - 子过程里开的游标（
DECLARE cur CURSOR）不会自动关闭，若异常跳过CLOSE语句，下次调用会报cursor already exists - 建议统一约定：所有子过程末尾加
RETURN 'SUCCESS'或RETURN 'ERROR: xxx'，外层用GET DIAGNOSTICS检查返回值
模块化不是为了好看，是让每一层只关心自己的输入输出契约。一旦发现某个子过程里开始写 IF @debug = 1 PRINT ... 或反复 SELECT INTO #tmp，说明它已经承担了不该有的职责。
