客户端只拿到第一个结果集是因为驱动默认不自动读取后续结果集，必须显式调用 nextresult()、nextset() 或 getmoreresults() 等接口切换；未加 set nocount on 易致消息行被误解析，引发错位或异常。
SQL Server 存储过程中用多个 SELECT 为什么客户端只拿到第一个结果集？
因为绝大多数数据库驱动（如 .NET 的 SqlClient、Python 的 pyodbc、Java 的 JDBC）默认只读取第一个结果集，后续的 SELECT 被直接忽略——这不是 bug，是设计行为。
必须显式调用“移动到下一个结果集”的接口，否则后续数据永远拿不到。
- .NET 中要用
SqlDataReader.NextResult()才能切换 - Python
pyodbc同样要调用cursor.nextset() - Java
Statement.execute()返回boolean，靠getMoreResults()判断并跳转 - Node.js
mssql包里需监听recordset事件多次，或用request.stream = true配合流式处理
SET NOCOUNT ON 对多结果集的影响有多大？
它不阻止结果集生成，但会抑制“X 行受影响”这类消息行。这些消息行在某些驱动中会被误判为结果集开头，导致后续解析错位甚至抛出 Invalid operation on closed recordset 类错误。
- 必须在存储过程开头加
SET NOCOUNT ON，尤其当过程里有INSERT/UPDATE时 - 不加的话，
pyodbc可能提前触发nextset()，把影响行当结果集；SqlClient在异步执行下更容易卡死 - 这个设置对性能无实质影响，但对稳定性是刚需
如何在 Python pyodbc 中安全接收多个结果集？
关键不是“怎么连”，而是“怎么一层层往下翻”。cursor.execute() 只执行，不自动推进；每个结果集都得手动捞完再调 nextset()。
cursor.execute("EXEC MyProc") while True: rows = cursor.fetchall() print(" 当前结果集行数：", len(rows)) if not cursor.nextset(): # 注意：返回 False 表示没下一个了 break-
nextset()返回None表示还有下一个，False表示已到底——别用is True判断 - 每次调
nextset()前，必须先把上一个结果集的数据读完（哪怕只调一次fetchone()），否则会报ProgrammingError: No results. Previous SQL was not a query. - 如果某结果集为空（0 行），
fetchall()返回空列表，不影响继续调nextset()
MySQL 或 PostgreSQL 能不能用同样方式处理多结果集？
不能。MySQL 的 mysqlclient 和 pymysql 不支持多结果集；PostgreSQL 的 psycopg2 默认也不支持——它们的协议层面就不允许单次执行返回多个结果集。
- SQL Server / Sybase 是少数原生支持该特性的数据库，别试图在 MySQL 里写多个
SELECT然后指望客户端收全 - PostgreSQL 可用
REFCURSOR+ 多个OUT参数模拟，但客户端要分别FETCH，逻辑更重 - 跨数据库可移植性需求强的场景，建议改用多次单查询 + 应用层合并，别依赖多结果集特性
多结果集不是“写完就能用”的功能，它的稳定接收高度依赖驱动实现细节和调用顺序。最容易被忽略的是： 没读完当前结果集就调 nextset()，或者忘了 SET NOCOUNT ON，这两点足以让整个流程静默失败。
