存储过程在数据库开发中承担着封装业务逻辑、减少网络交互、提升执行效率的重任。但许多存储过程在编写时默认调用方一定会传入合法参数，一旦传入空值、越界数字或不符合业务规则的字符串，轻则查询结果异常，重则误删数据、写入脏数据。要让存储过程真正可靠，就必须在过程体执行任何业务逻辑之前，先对输入参数进行一轮完整的预判验证。本文将从校验时机、常用校验手段和错误反馈机制三个方面展开讲解。
为什么参数校验必须放在存储过程开头
很多开发者习惯把参数校验分散在SQL语句的WHERE条件里，比如用ISNULL(@id, 0)来兜底。这种写法看似省事，实则掩盖了问题：当传入的ID为空时，查询不会报错，而是返回空结果集，调用方可能误以为数据不存在，进而触发删除或插入操作，最终破坏数据一致性。
正确的做法是在存储过程的第一行到业务逻辑之间设置一个“防御区”。这个区域只做三件事：检查参数是否为空、检查参数是否在合理范围内、检查参数是否满足业务前置条件。任何一个检查不通过，立即终止执行并抛出明确错误。这样做的最大好处是快速失败，问题在进入业务逻辑之前就被拦截，排查成本最低，回滚风险也最小。
此外，把校验集中放在开头还有维护上的优势。当参数规则变化时，只需要修改一处代码，而不是在几十行业务SQL里逐个排查隐含的假设条件。
常用参数预判手段与代码实现
参数校验通常分为四个层次：非空校验、类型与格式校验、范围校验、业务规则校验。下面以SQL Server的T-SQL为例，给出一个包含完整预判逻辑的存储过程骨架。
CREATE PROCEDURE dbo.usp_UpdateOrderStatus
@OrderId INT,
@NewStatus TINYINT,
@OperatorName NVARCHAR(50)
AS
BEGIN
SET NOCOUNT ON;
-- 第一层：非空校验
IF @OrderId IS NULL
THROW 50001, '参数 @OrderId 不能为空', 1;
-- 第二层：范围校验
IF @OrderId <= 0
THROW 50002, '参数 @OrderId 必须为正整数', 1;
IF @NewStatus NOT IN (0, 1, 2, 3)
THROW 50003, '参数 @NewStatus 只允许 0到3 的状态值', 1;
-- 第三层：格式校验（字符串长度）
IF LEN(ISNULL(@OperatorName, '')) = 0
THROW 50004, '参数 @OperatorName 不能为空字符串', 1;
IF LEN(@OperatorName) > 50
THROW 50005, '参数 @OperatorName 长度不能超过50', 1;
-- 第四层：业务规则校验（记录必须存在）
IF NOT EXISTS (SELECT 1 FROM dbo.Orders WHERE OrderId = @OrderId)
THROW 50006, '指定的订单不存在，无法更新状态', 1;
-- 业务逻辑（只有全部校验通过才会执行）
UPDATE dbo.Orders
SET Status = @NewStatus,
UpdateBy = @OperatorName,
UpdateTime = GETDATE()
WHERE OrderId = @OrderId;
END
这段代码体现了几个关键细节。第一，SET NOCOUNT ON放在开头，避免影响行数信息干扰调用方判断。第二，每个THROW语句使用了不同的错误编号，方便应用程序根据错误码做差异化处理。第三，错误消息中明确指出是哪个参数出了问题，调用方拿到消息就能直接定位，不需要反复试错。
对于字符串格式校验，比如邮箱、手机号，可以使用LIKE配合模式匹配。需要注意LIKE默认不区分大小写且不支持完整正则，如果模式较复杂，建议封装成独立的校验函数，保持存储过程主体清晰。
-- 手机号格式预判示例（SQL Server）
IF @Phone NOT LIKE '[1][3-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
THROW 50007, '参数 @Phone 不是合法的手机号格式', 1;
模式中每个方括号对应一个字符位置，[3-9]表示第二位必须是3到9之间的数字。虽然写法繁琐，但在不支持正则的数据库环境里这是最可靠的方案。
错误反馈机制的选择与跨数据库差异
校验失败后如何报告错误，直接影响调用方的处理体验。SQL Server提供了两种主要方式：RAISERROR和THROW。RAISERROR功能更丰富，支持格式化消息和自定义严重级别，但不会自动终止批处理；THROW语法更简洁，抛出后立即终止执行，语义上更接近其他语言的异常机制。除非有特殊需求，推荐优先使用THROW，并统一使用50000以上的自定义错误号。
在MySQL中，对应的机制是SIGNAL语句，写法略有不同但思路一致：
DELIMITER $$
CREATE PROCEDURE update_order_status(
IN p_order_id INT,
IN p_new_status TINYINT
)
BEGIN
-- 非空与范围预判
IF p_order_id IS NULL OR p_order_id <= 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '参数 p_order_id 必须为正整数';
END IF;
IF p_new_status NOT IN (0, 1, 2, 3) THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '参数 p_new_status 只允许 0到3 的状态值';
END IF;
-- 业务逻辑
UPDATE orders SET status = p_new_status WHERE order_id = p_order_id;
END$$
DELIMITER ;
注意MySQL中SQLSTATE '45000'是专门留给应用程序自定义错误的值，调用方在应用层捕获异常后可以直接读取MESSAGE_TEXT展示给用户。PostgreSQL则可以使用RAISE EXCEPTION，同样能达到立即中止并回滚当前事务的效果。
最后需要强调事务与校验的配合关系。如果存储过程内部开启了显式事务，校验逻辑应该放在BEGIN TRANSACTION之前，这样校验失败时根本不需要回滚；而一旦进入事务段，任何后续异常都应确保通过TRY CATCH块执行回滚，避免留下悬挂事务锁住资源。校验前移加上事务兜底，两层防护配合起来，存储过程的健壮性才能真正做到万无一失。