应将存储过程拆分为业务层与数据层两个独立过程：业务层负责校验、判断、调用并返回语义化结果码，数据层专注单点数据操作且不处理业务逻辑；参数类型长度精度须完全一致；事务仅在业务层控制；数据层禁止被应用直连。
存储过程怎么拆成“业务层+数据层”两部分
不能把所有逻辑塞进一个 CREATE PROCEDURE 里。真正可维护的分层，是让业务规则（比如“订单超时自动取消”）和数据操作（比如 UPDATE orders SET status = 'cancelled'）物理隔离——不是靠注释分块，而是拆成两个独立存储过程，由上层调用下层。
实操建议：
- 上层过程只做参数校验、业务判断、调用下层，并返回业务语义明确的结果码（如
@ret_code = 1001表示“库存不足”，而非 SQL 错误号） - 下层过程只接收已清洗/转换后的参数，专注单点数据操作，不查业务状态、不写日志、不抛自定义错误
- 两层之间用
OUTPUT参数或临时表传递中间结果，避免在上层反复查库 - 命名体现层级：
usp_Order_CancelByBusinessRule（业务层），usp_Order_UpdateStatus（数据层）
跨存储过程传参时哪些类型会悄悄丢精度或截断
varchar 和 datetime 是重灾区。比如上层传入 @order_no varchar(20)，下层声明为 @order_no varchar(10)，SQL Server 不报错，但值被无声截断；又比如上层用 GETDATE() 传 datetime，下层用 date 接收，秒级精度直接丢失。
实操建议：
- 所有跨过程参数，上下层声明必须完全一致：长度、精度、可空性（
NULLvsNOT NULL）全对齐 - 避免隐式转换：不用
datetime接datetime2，也不用int接bigint，哪怕看起来“够用” - 字符串统一用
varchar(max)或明确业务最大长（如订单号查表得最大长度），别凭感觉写varchar(50) - 调试时在下层开头加
IF LEN(@param) != LEN(LTRIM(RTRIM(@param))) RAISERROR('trim detected', 16, 1)捕获空格污染
事务控制该放在哪一层？嵌套事务为什么总出问题
事务边界必须且只能在最外层业务过程里开启和提交。下层数据过程如果自己写 BEGIN TRAN，遇上上层回滚，SQL Server 的 @@TRANCOUNT 会失衡，导致后续语句报错 The transaction ended in the trigger. The batch has been aborted.。
实操建议：
- 仅在顶层过程用
BEGIN TRY / BEGIN TRAN，下层过程一律不碰TRAN相关语句 - 下层过程内部需要原子性？用
SAVE TRAN @savepoint_name+ROLLBACK TO，但必须确保上层知道这个 savepoint 存在并配合处理 - 上层调用多个下层过程时，检查每个的
@@ERROR，任一失败立即ROLLBACK，不要等全部执行完再判 - 避免在触发器或函数里调用这些分层过程——它们天然无法参与外部事务
如何让模块化后的存储过程还能被应用直连调用
分层后，应用通常只该调用业务层过程，但开发常因“方便”直接调数据层，绕过校验和日志。这不是权限问题，是接口契约被破坏。
实操建议：
- 给数据层过程名加前缀，如
usp_core_或usp_data_，并在文档中明确标注“禁止应用直连” - 用
EXECUTE AS OWNER配合数据库角色，让应用账户只有业务层过程的EXECUTE权限，对数据层显式DENY - 在数据层过程开头加校验：
IF ORIGINAL_LOGIN() NOT IN ('AppUser', 'JobAgent') RAISERROR('Direct call forbidden', 16, 1) - 监控
sys.dm_exec_query_stats中高频调用的数据层过程，及时找人对齐使用意图
分层不是加一堆 CREATE PROCEDURE 就完事，关键在调用链是否单向、参数是否零损耗、事务是否不越界——这三个地方一旦松动，模块就退化成套娃式黑盒，比单体还难 debug。
