在编写SQL Server存储过程时，经常会遇到需要循环处理海量数据、批量导入或复杂计算的情况。这类操作往往耗时几分钟甚至几小时，如果过程内部没有任何输出，调用方就只能被动等待，无法判断任务是卡死还是正常推进。利用RAISERROR与PRINT语句，可以在过程执行期间向客户端发送文本消息，从而实现执行进度的实时监控。
一、PRINT语句的基础用法与局限
PRINT是SQL Server中最简单的消息输出方式，它可以将字符串、变量或表达式的结果发送到客户端消息窗口。在存储过程的各个处理阶段插入PRINT，是最直观的进度通知手段。例如我们在每处理完一万行数据时打印一次当前进度。
下面的示例展示了一个使用PRINT输出循环进度的简单存储过程。注意PRINT只能输出字符串类型，如果拼接数字需要使用STR或CONVERT进行转换。
CREATE PROCEDURE dbo.usp_ProcessBigTable_Print
AS
BEGIN
SET NOCOUNT ON;
DECLARE @i INT = 0;
DECLARE @total INT = 100000;
WHILE @i < @total
BEGIN
-- 模拟处理一小批数据
SELECT @i = @i + 1000;
PRINT '已处理行数：' + CONVERT(VARCHAR(20), @i);
END
PRINT '处理完成';
END
PRINT的最大问题是消息缓冲机制。SQL Server默认会将PRINT产生的消息放入服务端缓冲区，直到整个批处理结束或者缓冲区被填满，才会一次性发送给客户端。这意味着在上面的循环中，你可能要等到过程完全跑完，才能在SSMS的消息窗口看到所有PRINT内容，根本起不到实时监控的作用。
此外，在应用程序中调用该存储过程时，像ADO.NET这样的数据访问组件并不会把PRINT消息作为异常或结果集返回，而是触发连接对象的InfoMessage事件。如果程序没有显式订阅该事件，这些消息就会被直接丢弃，开发者甚至以为过程没有任何输出。
二、RAISERROR配合WITH NOWAIT实现实时推送
RAISERROR原本用于抛出错误和警告，但它有一个非常实用的功能：通过指定严重度（severity）低于11并且使用WITH NOWAIT选项，可以立即将消息刷新到客户端，而不受缓冲机制限制。这正是实现实时进度监控的关键。
WITH NOWAIT会告诉SQL Server不要缓存这条消息，马上发给调用方。由于严重度在1到10之间属于信息性消息，不会中断存储过程执行，因此非常适合做进度汇报。下面改写前面的例子：
CREATE PROCEDURE dbo.usp_ProcessBigTable_Raiserror
AS
BEGIN
SET NOCOUNT ON;
DECLARE @i INT = 0;
DECLARE @total INT = 100000;
DECLARE @msg NVARCHAR(200);
WHILE @i < @total
BEGIN
SELECT @i = @i + 1000;
SET @msg = N'已处理行数：' + CONVERT(NVARCHAR(20), @i);
RAISERROR(@msg, 0, 1) WITH NOWAIT;
END
RAISERROR(N'处理完成', 0, 1) WITH NOWAIT;
END
在SSMS中执行这个存储过程，你会看到每处理一千行，消息窗口就立刻多出一行进度，而不需要等循环结束。对于需要在生产环境长时间运行的维护脚本，这种即时反馈能帮助DBA快速发现异常，比如某一批耗时突然变长，就可以及时评估是否终止。
在应用程序侧，RAISERROR带NOWAIT发送的消息同样会进入InfoMessage事件（以SqlConnection为例），而不是抛出异常。因此代码里应当挂载该事件并把e.Message记录下来，才能在日志系统里看到实时进度。如果严重度设置为11或更高，RAISERROR会中断执行并触发异常，那种用法不属于进度播报范畴。
三、两种方式的对比与最佳实践
从实时性角度看，RAISERROR ... WITH NOWAIT明显优于PRINT，因为它绕过了缓冲。从书写便利性看，PRINT不需要考虑严重度和状态参数，语法更轻量。两者在消息长度上也有差异：PRINT最长支持8000字符（非Unicode）或4000字符（Unicode），RAISERROR的文本长度受nvarchar限制，但日常进度说明完全够用。
在实际项目中，推荐统一使用RAISERROR配合NOWAIT来输出进度，同时将关键阶段信息同时写入日志表。这样既有客户端实时可见性，也有持久化记录供事后审计。下面的表格总结了主要区别：
| 对比项 | RAISERROR WITH NOWAIT | |
|---|---|---|
| 实时性 | 差，受缓冲影响 | 好，立即发送 |
| 语法复杂度 | 简单 | 需指定严重度与状态 |
| 客户端获取方式 | InfoMessage事件 | InfoMessage事件 |
| 是否中断执行 | 否 | 否（严重度小于11时） |
为了避免在循环里过于频繁地发送消息导致网络开销，可以设置每处理固定批量（如五万行）才汇报一次。另外，如果存储过程可能被Agent作业调用，作业历史仅记录最终输出，中间RAISERROR消息不会留痕，所以重要节点仍建议写表日志。
最后给出一个综合示例，它在每十万行汇报进度，并把阶段记录插入监控表：
CREATE PROCEDURE dbo.usp_SafeImport
AS
BEGIN
SET NOCOUNT ON;
DECLARE @done BIGINT = 0;
DECLARE @batch BIGINT = 100000;
DECLARE @txt NVARCHAR(200);
WHILE 1 = 1
BEGIN
-- 假设每次更新十万行，受影响行数存入@done
UPDATE TOP (100000) dbo.Target
SET Flag = 1
WHERE Flag = 0;
IF @@ROWCOUNT = 0 BREAK;
SELECT @done = @done + @batch;
SET @txt = N'已导入约' + CONVERT(NVARCHAR(20), @done) + N'行';
RAISERROR(@txt, 0, 1) WITH NOWAIT;
INSERT INTO dbo.ProcLog(step_name, log_time)
VALUES(@txt, GETDATE());
END
RAISERROR(N'导入全部完成', 0, 1) WITH NOWAIT;
END
通过上述方式，无论是开发人员调试还是运维监控，都能清晰掌握存储过程的实时执行进度，并在必要时快速介入，避免无效等待和资源浪费。