听起来你已经做了非常扎实的前期排查——排除了参数嗅探和查询计划问题，而且通过live query statistics（实时查询统计）确认了存储过程内部执行耗时其实很短，问题出在结果返回阶段。这种情况通常和数据传输、客户端处理或者SQL Server的结果集处理环节有关，下面是几个可以重点排查的方向：

• 结果集大小与网络传输瓶颈：
  如果存储过程返回的结果集规模波动很大（比如某些参数触发返回几十万甚至上百万行数据），即使SQL Server端快速处理完逻辑，把数据从服务器传输到SMSS客户端也可能花费大量时间，尤其是网络带宽有限或者存在波动的时候。你可以先统计每次执行返回的行数/数据量差异——这往往是返回延迟的核心原因之一。

• SMSS客户端的渲染与处理开销：
  SMSS在接收结果集后，需要把数据渲染成可视化表格展示，这个过程也可能产生显著耗时。特别是当结果集包含大字段（比如VARCHAR(MAX)、VARBINARY(MAX)、复杂XML/JSON）时，客户端解析和渲染这些内容的速度会远慢于普通字段。你可以换用sqlcmd工具执行存储过程，对比返回结果的时间：如果sqlcmd执行快很多，那基本可以确定是SMSS客户端的渲染/处理拖慢了整体速度。

• SQL Server的结果集输出等待：
  你可以在执行存储过程前后，查看当前会话的等待统计（通过sys.dm_exec_session_wait_stats），重点关注ASYNC_NETWORK_IO这类等待类型。如果这个等待的累计时间占比很高，说明SQL Server已经生成完结果，但一直在等待客户端接收数据——这通常指向网络传输或者客户端接收能力的问题。另外，还要检查是否因为内存授予不足，导致结果集需要写入tempdb再分批传输，这也会增加返回延迟。

• 存储过程的输出细节优化：
  确认存储过程里是否开启了SET NOCOUNT OFF——这个设置会让SQL Server返回大量“XX行受影响”的消息，这些额外消息会增加传输和客户端处理的时间，改成SET NOCOUNT ON通常能缓解。另外，检查是否有最后阶段的游标遍历、临时表批量写入等操作，这些操作可能在实时统计里没被计入“执行耗时”，但会延迟结果集的生成和返回时机。

内容的提问来源于stack exchange，提问作者Erikest