存储过程复用核心在于参数设计合理、逻辑边界清晰、调用方式稳定；应仅保留影响执行路径的非空IN参数，避免冗余字段和动态SQL，每个过程只做一件事，并显式授予EXECUTE权限。
能复用的存储过程，核心不在“写得长”，而在“参数设计合理、逻辑边界清晰、调用方式稳定”。
怎么定义输入参数才不容易出错
参数是存储过程对外暴露的唯一接口，乱设参数等于把门敞开给调用方踩坑。常见错误是把业务字段全塞进去，比如 @BillingAddress、@ShippingAddress 这类非核心字段直接当参数传——它们该走关联表或外部服务，不该进存储过程体。
- 只保留真正影响执行路径的参数，例如
@OrderID、@Status、@UpdatedBy - 所有
IN参数必须声明非空约束（如@OrderID INT NOT NULL），避免后续逻辑里反复判空 - 对可选行为用布尔型参数控制，而不是靠传
NULL区分，例如@SkipValidation BIT = 0比@ValidateFlag VARCHAR(1) = NULL更直观、更难误用 - 避免用
VARCHAR(MAX)接收结构化数据（如 JSON 字符串），真要传复杂结构，优先考虑表值参数（TABLE类型）或拆成多个明确字段
为什么不能把所有SQL都堆在一个存储过程里
一个叫 usp_ProcessOrder 的过程里塞了查库存、扣减、生成日志、发通知、更新状态……这不是封装，是埋雷。下次改发通知逻辑，就得测试整条链路，连带库存计算也得重验。
- 每个存储过程只做一件事：比如
usp_ReserveStock只负责锁定库存，usp_CreateShipment只负责生成运单 - 调用方按需组合，而不是让一个过程承担全部职责；上层应用或另一个存储过程来编排流程
- 拆分后，单个过程更容易加索引、加事务控制、加单元测试，也方便单独启用/禁用某环节（比如临时关闭日志写入）
- 注意嵌套调用深度：SQL Server 默认递归层级是 32，但实际建议不超过 3 层，否则出错时堆栈难定位，性能也容易抖动
如何让存储过程真正被其他系统安全调用
光写出来没人用，或者用了但权限失控，等于白干。很多团队卡在“谁该有权限执行这个过程”这一步。
- 不要给用户
db_datareader或db_datawriter角色，而是显式授予EXECUTE权限，例如：GRANT EXECUTE ON usp_UpdateOrder TO [AppUser] - 避免在过程内用动态 SQL 拼接表名或字段名（如
EXEC('UPDATE ' + @TableName + ' SET ...')），这会绕过权限检查，且无法预编译 - 输出结果尽量统一用
SELECT返回结果集，少用OUTPUT参数或返回码——前者难调试，后者容易被调用方忽略 - 如果必须返回状态，用标准约定：成功返回 0，业务异常返回负数（如 -1 库存不足，-2 订单不存在），并在注释里写明每种码含义
真正难的不是写完一个能跑的存储过程，而是让它在三个月后还能被新同事一眼看懂、放心修改、安全调用。边界感、命名一致性、权限粒度，这些细节比语法本身更决定复用成败。
