select是最直接通用的结果集返回方式，需确保仅一个裸select作为最终输出、字段别名明确、单行用top 1或强where；output参数适合标量值但须两端声明output关键字；return仅限整数状态码，不可作业务数据通道。
SELECT 是最直接、最通用的结果集返回方式
业务系统（比如 C# 的 SqlCommand、Python 的 pyodbc、Java 的 JDBC）默认就是靠读取结果集来拿数据的，而 SQL Server 存储过程中只要有一条裸 SELECT（不带 INTO、不带变量赋值），它就会原样发给客户端——这就是结果集。
常见错误现象：调用后拿到空结果、字段名乱码、多结果集干扰后续逻辑。
- 必须确保该
SELECT是最终输出逻辑，且只执行一次；前面若有其他SELECT（哪怕只是调试用的PRINT替代品），客户端会收到多个结果集，ExecuteScalar()只取第一个，SqlDataReader不调NextResult()就卡住 - 字段别名要明确，避免
SELECT Name, Salary FROM ...在客户端映射成Column1/Column2；推荐写成SELECT Name AS [Name], Salary AS [Salary] - 如果必须限制单行，用
TOP 1或强 WHERE 条件，而不是依赖业务逻辑“应该只有一条”——否则线上查出两行，应用层就可能抛异常或取错数据 - 在 SSIS 或动态 SQL 中用
EXEC ... WITH RESULT SETS时，列名和类型必须完全匹配，否则报错；例如WITH RESULT SETS (([Name] NVARCHAR(50), [Amount] DECIMAL(18,2)))
OUTPUT 参数适合返回标量值，但调用端必须配合处理
当你只需要一个 ID、一个状态码、一个计数，而不是表格数据时，OUTPUT 参数比结果集更轻量，也不占结果集通道。但它不是“自动生效”的，两端漏写 OUTPUT 关键字，值就传不出来。
常见错误现象：调用后变量仍是 NULL、字符串被截断、值在读完结果集前就去取导致读不到。
- 定义存储过程时：参数声明必须带
OUTPUT，如@order_id INT OUTPUT；不写就是纯输入参数 - 调用时：
EXEC usp_CreateOrder @cust_id = 123, @order_id = @out_id OUTPUT—— 这里OUTPUT缺不得，少写就等于没传 -
@out_id必须提前DECLARE，不能临时拼接；未声明就传入会报Must declare the scalar variable - 如果存储过程里还有
SELECT，那@order_id的值要等所有结果集被消费完才就绪；在 ADO.NET 中，必须先reader.Read()、再reader.NextResult()直到返回false，再读command.Parameters["@order_id"].Value - NVARCHAR 类型容易静默截断：声明
@msg NVARCHAR(20)却赋值'Order created successfully'，最终只拿到前 20 字符；建议统一用NVARCHAR(MAX)，调用端SqlParameter.Size = -1
别把 RETURN 当数据通道用
RETURN 只能返回整数，且仅用于状态反馈——成功是 0，找不到是 1，权限不足是 -2 等。把它当业务数据传，99% 的情况会丢数据。
常见错误现象：C# 里用 ExecuteNonQuery() 调用后发现返回值是 0，但实际想要的订单号根本没拿到；或者 RETURN @amount 导致小数全变整数、字符串变 0。
-
RETURN返回值类型强制为INT，DECIMAL(18,2)、NVARCHAR、DATETIME全部被隐式转换，精度丢失不可逆 - .NET 的
ExecuteNonQuery()根本不解析RETURN值；要用ExecuteScalar()+Parameters才能拿到，但前提是存储过程里还写了SELECT或OUTPUT，否则光靠RETURN拿不到任何业务数据 - SSMS 里看起来“能拿到”，是因为界面自动提取了
RETURN值；程序里不显式绑定参数并读取，就等于没传 - 真正该用
RETURN的地方：快速反馈执行状态，比如插入失败时RETURN 50001，上层用@@ERROR或TRY/CATCH处理
嵌套调用或多结果集场景下，客户端必须主动管理结果流
SQL Server 允许一个存储过程里多次 SELECT，也支持嵌套调用另一个带结果集的过程。但这意味着客户端收到的不是“一张表”，而是一串结果集流——不手动遍历，就只能拿到第一个。
常见错误现象：调用方只取了第一张结果集，后面几个全丢；或者用 ExecuteScalar() 试图读第二张表的值，结果永远是 NULL。
- 在 .NET 中，必须用
SqlDataReader并循环调用NextResult()，直到返回false，才能确保所有结果集都被消费，OUTPUT参数才就绪 - Python 的
pyodbc同样需要cursor.nextset()；不调就停在第一个结果集上 - SSIS 的 OLE DB Source 默认只认第一个结果集；若要取后续的，得改用“SQL command from variable”+ 自定义结果集映射，或拆成多个 Execute SQL Task
- 如果真需要多个结构不同的结果集，建议拆成多个独立存储过程，比在一个里塞一堆
SELECT更易维护、更少歧义
业务系统调用存储过程时，真正麻烦的从来不是“怎么写”，而是“怎么收”——结果集顺序、OUTPUT 就绪时机、字符串截断边界、多结果集遍历，这些细节稍一疏忽，数据就悄无声息地丢了。
