业务系统调用 SQL Server 存储过程时，问题往往不在“过程能不能执行”，而在“结果能不能被稳定拿到”。同样是返回数据，SELECT、OUTPUT、RETURN 面向的是三类完全不同的需求；一旦选错通道，最常见的后果就是空结果、值为 NULL、类型被截断，或者客户端只拿到第一张表。
这篇文章把几种返回方式按业务调用习惯拆开讲清楚，并把容易踩坑的细节放到同一条判断线上：你可以据此判断该返回结果集还是标量值、调用端需要做哪些配合，以及多结果集时为什么必须主动管理结果流。
用 SELECT 返回结果集：最通用，但要保证输出干净
通常情况下，业务系统，比如 C# 的 SqlCommand、Python 的 pyodbc、Java 的 JDBC，都是通过读取结果集来获取数据。在 SQL Server 存储过程中，只要有一条不带 INTO、也没有变量赋值的裸 SELECT 语句，它就会将查询结果直接发送给客户端，这就是最常见的结果集返回方式。
这一方式最直接，但也最容易因为“过程里多写了一点东西”而出问题。典型现象包括：调用后拿到空结果、字段名映射异常、多结果集打乱后续逻辑。
把裸 SELECT 作为最终输出，而且只输出一次
如果前面还有其他 SELECT，哪怕只是临时调试用途，客户端收到的也会是多个结果集。此时 ExecuteScalar() 只会取第一个结果，SqlDataReader 如果不继续调用 NextResult()，后面的数据就不会被正确消费。
字段名和结果结构要显式写清楚
字段别名最好明确声明，避免类似 SELECT Name, Salary FROM ... 被客户端映射成 Column1、Column2。更稳妥的写法是：
SELECT Name AS [Name], Salary AS [Salary]如果在 SSIS 或动态 SQL 中使用 EXEC ... WITH RESULT SETS，列名和类型还必须与声明完全一致，否则会直接报错，例如：
WITH RESULT SETS (([Name] NVARCHAR(50), [Amount] DECIMAL(18,2)))需要单行时，用 TOP 1 或强 WHERE 明确收口
如果业务只允许返回一行，不要依赖“按理说只会查到一条”。更安全的做法是直接用 TOP 1 或足够强的 WHERE 条件限制结果范围。否则一旦线上查出两行，应用层就可能抛异常，或者悄悄取错数据。
用 OUTPUT 返回标量值：轻量，但调用两端必须对齐
当你只需要一个 ID、一个状态码、一个计数，而不是一张表格时，OUTPUT 参数通常比结果集更合适。它更轻量，也不会占用结果集通道。但它不是“写了就能取到”，定义端和调用端都必须显式使用 OUTPUT 关键字。
这一类问题的常见表现是：调用后变量仍然是 NULL、字符串被截断，或者在结果集还没读完之前就去取值，导致参数似乎“没有返回”。
过程定义和 EXEC 调用都不能漏写 OUTPUT
定义存储过程时，参数声明必须带 OUTPUT，例如：
@order_id INT OUTPUT调用时也必须再次写出 OUTPUT：
EXEC usp_CreateOrder @cust_id = 123, @order_id = @out_id OUTPUT这里少写一次，效果就等于没有把输出参数传出来。
输出变量要先声明，取值时机也要对
@out_id 必须提前 DECLARE，不能临时拼接传入；否则会报 Must declare the scalar variable。
另外，如果存储过程中同时还有 SELECT，那么 OUTPUT 参数的值通常要等所有结果集都被消费完之后才算就绪。在 ADO.NET 中，常见处理方式是先读取结果，再持续调用：
reader.Read()
reader.NextResult()直到 NextResult() 返回 false，最后再读取：
command.Parameters["@order_id"].ValueNVARCHAR 长度不够时会静默截断
这是实际项目里非常常见的一类问题。比如声明 @msg NVARCHAR(20)，却赋值 'Order created successfully'，客户端最终拿到的只会是前 20 个字符。为了减少这类隐性错误，可以统一使用 NVARCHAR(MAX)，调用端则配合设置 SqlParameter.Size = -1。
RETURN 只能做状态码，不要拿来传业务数据
RETURN 在 SQL Server 里只适合做执行状态反馈，例如成功返回 0，找不到返回 1，权限不足返回 -2。它不是业务数据通道，把订单号、金额、字符串、日期塞进 RETURN，大多数情况下都会出问题。
最典型的现象是：C# 里调用 ExecuteNonQuery() 后看见返回值是 0，但真正需要的订单号根本没拿到；或者 RETURN @amount 之后，小数直接变整数，字符串则变成 0。
RETURN 的返回类型强制是 INT
DECIMAL(18,2)、NVARCHAR、DATETIME 这类值放进 RETURN 时，都会发生隐式转换，精度或内容丢失后无法恢复。这里不是“有损”，而是根本不适合拿来承载业务字段。
程序里不会像 SSMS 那样帮你自动处理
SSMS 里看起来“能拿到 RETURN 值”，很多时候只是因为界面替你做了额外显示。到了程序调用阶段，`.NET` 的 ExecuteNonQuery() 并不会替你解析业务数据；要配合 ExecuteScalar() 和 Parameters 才能显式读取相关返回信息，而且前提仍然是过程里同时使用了 SELECT 或 OUTPUT。如果只有 RETURN，那它也只适合表达状态，不适合回传业务内容。
真正适合 RETURN 的场景
更合理的用法是快速反馈执行状态，例如插入失败时：
RETURN 50001再由上层结合 @@ERROR 或 TRY/CATCH 处理。这种分工清晰，也更符合 SQL Server 的机制边界。
多结果集和嵌套调用下，客户端必须管理结果流
SQL Server 允许一个存储过程中多次 SELECT，也支持嵌套调用另一个会返回结果集的过程。这意味着客户端接收到的并不一定是“一张表”，而是一串结果流。如果调用端不主动遍历，通常只能拿到第一张结果集。
常见错误包括：调用方只读了第一张表，后续结果全部丢失；或者使用 ExecuteScalar() 试图读取第二张结果集中的值，结果永远得到 NULL。
.NET 里要显式循环 NextResult()
在 `.NET` 中，必须使用 SqlDataReader 并循环调用 NextResult()，直到返回 false。只有这样，所有结果集才算被完整消费，相关的 OUTPUT 参数也才会处于可读状态。
Python pyodbc 也要继续调用 nextset()
如果使用 Python 的 pyodbc，同样需要调用 cursor.nextset()。不继续切换结果集，程序就会停留在第一张表上，后续数据不会自动出现。
SSIS 默认通常只认第一张结果集
在 SSIS 里，OLE DB Source 默认只识别第一个结果集。若确实要消费后续结果，通常需要改用“SQL command from variable”并做自定义结果集映射，或者直接拆成多个 Execute SQL Task。
结构差异大的多结果集，通常拆过程更稳妥
如果确实需要返回多个结构不同的结果集，维护上往往更推荐拆成多个独立存储过程，而不是在一个过程中堆很多个 SELECT。这样对调用端更清晰，也能减少“到底该取第几张表”的歧义。
怎么选返回方式：按数据形态而不是按习惯
归纳起来，选择标准并不复杂：
- 要返回表格数据，优先用单一、干净、结构明确的
SELECT - 只需要一个 ID、计数或状态文本，优先用
OUTPUT - 只表达成功失败或错误编号，才使用
RETURN - 一旦存在多结果集或嵌套调用，调用端就必须显式遍历结果流
业务系统调用存储过程时，真正容易出问题的，从来不是 SQL 能不能跑通，而是调用方是否按 SQL Server 的返回规则去接收。把结果通道、读取时机和结果流管理这三件事理顺，很多“线上偶发拿不到值”的问题其实都能提前避开。
