SQL Server存储过程中参数校验应前置：用IF+IS NULL判空、LEN()验字符串长度、数值范围检查等，避免在INSERT/UPDATE后才发现错误；ISNULL仅用于NULL替换，NULLIF用于相等转NULL，TRY_CAST仅作类型转换，均不能替代显式业务校验。
存储过程里怎么判断输入参数是否合法
参数校验不能只靠应用层，存储过程必须自己拦住脏数据。SQL Server 的 ISNULL、NULLIF 和 TRY_CAST 是基础工具，但更关键的是用 IF 显式检查边界和业务规则。
常见错误是把校验逻辑写在 INSERT/UPDATE 之后——等执行完才发现主键冲突或长度超限，事务已部分生效，回滚成本高。
- 字符串参数优先用
LEN(@param) > 0 AND LEN(@param) ，别只判 <code>IS NULL，空字符串也要拦 - 数值参数用
TRY_CAST(@id AS INT) IS NULL比直接CAST安全，避免运行时报错中断流程 - 日期参数建议统一转成
DATE类型再比大小，避免DATETIME带时分秒引发隐式转换偏差
怎么让验证失败时返回清晰的错误信息
用 RAISERROR（SQL Server）或 SIGNAL（MySQL 5.5+）主动抛错，比让数据库报 Violation of PRIMARY KEY constraint 这类通用错误有用得多。
错误消息要包含参数名和实际值，方便调用方快速定位。比如传入负数金额，就该提示“@amount must be greater than 0, got -120.5”。
- SQL Server 中优先用
RAISERROR('Invalid @status: %s', 16, 1, @status)，级别 16 表示用户错误，可被客户端捕获 - 避免在
RAISERROR前执行任何 DML，否则可能造成部分写入 + 错误返回的混乱状态 - MySQL 存储过程中，
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid email format'是标准写法，不要用SELECT 'error'这种伪返回
外键关联数据存在性验证要不要查表
要查，但得控制方式。直接在主逻辑里写 SELECT COUNT(*) FROM users WHERE id = @user_id 看似稳妥，其实引入了额外 IO 和锁竞争，尤其高并发时容易拖慢整个过程。
更健壮的做法是：先用 EXISTS 快速探查，且把查询放到事务最开始；或者干脆依赖外键约束本身，用 TRY...CATCH 捕获违反约束的错误并包装成业务提示。
IF NOT EXISTS (SELECT 1 FROM products WHERE sku = @sku) BEGIN RAISERROR('Product %s not found', 16, 1, @sku) RETURN END- 如果表有唯一索引且业务上必须强一致，不如省掉显式查询，让 INSERT/UPDATE 失败后在
CATCH块里解析ERROR_NUMBER()，比如 547 是外键错误，针对性处理 - 注意
EXISTS子查询别漏加WITH (NOLOCK)（SQL Server），否则可能被其他事务阻塞
验证逻辑放在事务内还是事务外
全部放事务内。看起来“先校验再提交”更顺，但实际中校验本身可能涉及读取其他表（比如检查用户余额）、调用函数（比如验证手机号格式），这些操作如果不在事务里，就可能出现校验通过后、真正执行前，被其他会话改掉前提条件的情况。
典型例子：校验库存充足 → 事务外返回 true → 其他会话扣减库存 → 当前事务执行扣减时超卖。所以校验和操作必须原子化。
- 事务从
BEGIN TRY或START TRANSACTION开始，第一件事就是跑所有前置验证 - SQL Server 中慎用
SET XACT_ABORT ON，它会让运行时错误自动回滚，但也可能把本可恢复的警告（如截断警告）也当致命错误处理 - MySQL 的
DECLARE EXIT HANDLER FOR SQLEXCEPTION要覆盖所有可能出错点，包括验证阶段的SIGNAL
验证逻辑越贴近真实数据状态，越容易漏掉并发场景下的竞态条件。别嫌麻烦，每个 IF 后面都想想：这一行执行完到下一行之间，有没有人能改掉我刚读过的那条记录。
