一、RAISERROR函数的核心定位

在数据库开发中，错误处理是保障系统稳定性的关键环节。RAISERROR作为系统提供的核心函数，允许开发者定义并触发自定义错误消息，实现业务逻辑校验、数据完整性检查及审计日志记录等场景需求。该函数通过将用户定义的错误信息存储在系统消息表中，形成标准化的错误处理机制，其设计理念与C语言的PRINTF函数存在相似性，但针对数据库环境进行了专项优化。

1.1 系统消息存储机制

所有用户定义的错误消息均存储在sys.messages系统表中，该表采用三列结构：

message_id：唯一标识符（用户定义需>50000）
language：语言标识（如us_english）
text：错误消息模板（支持格式化参数）

系统预留50000号错误作为特殊标识，14000号用于标准消息模板。这种分层设计既保证系统消息的优先级，又为用户自定义消息预留充足空间。

1.2 错误号分配规范

错误号遵循严格分配规则：

0-49999：系统保留范围
50000：特殊消息标识
50001+：用户自定义消息
50000-59999：临时性业务错误
60000+：持久性系统错误

这种分配策略避免与系统内置错误冲突，同时为不同业务场景提供分类依据。例如某金融系统将50001-50100用于交易校验错误，50101-50200用于权限控制错误。

二、消息格式化参数详解

RAISERROR支持类似C语言的格式化语法，通过占位符实现动态内容插入。其参数体系包含三大类：

2.1 对齐控制参数

RAISERROR('订单金额:%*s', 10, 2, 100.50)
-- 输出："订单金额:     100.50"（右对齐，宽度10）

%*s：动态宽度字符串
第一个参数(10)：总显示宽度
第二个参数(2)：实际值（此处无效，仅占位）
第三个参数：真实插入值

2.2 数值格式化参数

RAISERROR('温度异常:%.*f°C', 2, 37.4567)
-- 输出："温度异常:37.46°C"（保留2位小数）

%.*f：动态精度浮点数
第一个参数(2)：小数位数
第二个参数：真实值

2.3 类型修饰符

修饰符	适用类型	示例
h	short	%hd
l	long	%ld
ll	long long	%lld

DECLARE @val BIGINT = 123456789012
RAISERROR('大整数:%lld', 1, 0, @val)

三、典型应用场景实践

3.1 业务逻辑校验

CREATE PROCEDURE usp_TransferFunds
    @fromAccount INT,
    @toAccount INT,
    @amount DECIMAL(18,2)
AS
BEGIN
    IF @amount <= 0
        RAISERROR('转账金额必须大于0', 16, 1)
    IF NOT EXISTS (SELECT 1 FROM Accounts WHERE AccountID = @fromAccount)
        RAISERROR('源账户不存在(50001)', 16, 1, 50001)
    -- 正常转账逻辑...
END

通过自定义错误号实现：

16级严重性（用户可纠正错误）
50001号标识具体业务错误
参数化消息提升可维护性

3.2 审计日志记录

CREATE TRIGGER trg_AuditUserChanges
ON Users
AFTER UPDATE
AS
BEGIN
    DECLARE @msg NVARCHAR(200)
    SET @msg = '用户%s(ID:%d)信息被修改，修改时间:%s'
    DECLARE @userName NVARCHAR(50) = (SELECT UserName FROM inserted)
    DECLARE @userId INT = (SELECT UserID FROM inserted)
    RAISERROR(@msg, 10, 1, @userName, @userId, CONVERT(NVARCHAR, GETDATE(), 120))
    -- 10级严重性（仅记录不中断）
END

3.3 错误链追踪

BEGIN TRY
    -- 调用可能出错的过程
    EXEC usp_ProcessOrder 12345
END TRY
BEGIN CATCH
    DECLARE @errorMsg NVARCHAR(4000) = 
        '原始错误:%s, 订单号:%d, 追踪ID:%s'
    RAISERROR(@errorMsg, 16, 1, 
        ERROR_MESSAGE(), 
        12345, 
        NEWID())
END CATCH

四、最佳实践指南

4.1 错误号管理策略

建立错误号分配文档
按模块划分号段（如50001-50100用于订单模块）
预留20%号段作为扩展空间
避免使用系统保留范围（0-49999）

4.2 消息模板设计原则

包含关键业务标识（如订单号、用户ID）
使用参数化设计避免字符串拼接
保持消息简洁（建议<200字符）
包含错误分类标识（如[VALIDATION]前缀）

4.3 性能优化建议

预编译常用错误消息
避免在循环中频繁调用
严重性10以下错误考虑异步记录
批量操作使用表变量收集错误

五、与THROW的对比分析

特性	RAISERROR	THROW
引入版本	SQL 2000	SQL 2012
参数灵活性	高（支持格式化）	低（固定参数）
错误号范围	自定义	50000+
事务控制	不自动回滚	自动回滚
嵌套调用	支持	不支持

建议新项目优先使用THROW，但需注意其局限性：

无法动态生成错误消息
严重性固定为16
不支持自定义错误号

六、扩展应用场景

6.1 多语言支持

通过sys.messages表的language列实现：

-- 添加英文消息
EXEC sp_addmessage 
    @msgnum = 50002, 
    @severity = 16, 
    @msgtext = 'Invalid password format', 
    @lang = 'us_english'
-- 添加中文消息
EXEC sp_addmessage 
    @msgnum = 50002, 
    @severity = 16, 
    @msgtext = '密码格式无效', 
    @lang = '简体中文'

6.2 与日志服务集成

CREATE PROCEDURE usp_LogError
    @errorNumber INT,
    @message NVARCHAR(4000),
    @severity INT
AS
BEGIN
    -- 写入系统日志表
    INSERT INTO ErrorLogs 
    VALUES (@errorNumber, @message, GETDATE(), SYSTEM_USER)
    -- 同时触发RAISERROR
    DECLARE @sysMsg NVARCHAR(4000) = 
        '系统错误[%d]:%s 发生时间:%s'
    RAISERROR(@sysMsg, @severity, 1, 
        @errorNumber, 
        @message, 
        CONVERT(NVARCHAR, GETDATE(), 120))
END

通过这种分层设计，既保证实时错误通知，又实现持久化存储供后续分析。这种模式在金融、医疗等高可靠性要求的系统中得到广泛应用。

RAISERROR函数详解：自定义错误处理与消息管理