我有一个查询，左连接 100 多个表并返回 2,000 多列，但只有几行（10-20）。这部分目前不在我的控制范围内，它过去可以在少一些列的情况下正常运行（可能在正常的非宽表宽度下）。编译初始计划后执行是“即时”的，我实际上并没有将所有结果返回给客户端。如果我返回 1 行，它是即时的并立即返回结果。
当我返回所有 11 个左右的结果时，它会下降到大约需要 15 秒。但是，如果我添加任何“FOR XML [RAW [ELEMENTS, XSINIL]]”迭代，它也会立即返回所有结果以及 XML 开销。据我所知，这排除了查询的实际执行，并将其隔离到正在计算的查询结果和它们被发送到客户端之间。
我一直在寻找大约 4 天的时间来解释这一点。有没有办法通过结果集获得 XML 速度？为什么要这样做？
在 2008R2 和 2016 上尝试过 TCP/IP 和命名管道
更新
根据反馈，对于表格结果，发生的是第一次通过，大约需要 20 秒。SSMS 中的计时器一直运行到大约 11 秒，然后停止。然后，当显示结果时，计时器跳至 20 秒。下一次运行时计时器会挂起，然后在显示结果时，计时器会弹出大约 9-11 秒。
通过将主表的唯一 id 与表函数连接来选择 11 行的方式。我尝试用临时表替换表函数。为了选择一条记录，我基本上将数据传递到导致一个结果的表函数中。我也尝试使用直接的 id = 文字数字。对于那些，计时器在结果显示之前甚至不会离开 0。
我无法“插入”临时表，因为常规表的列太多。我也无法在其上创建索引视图来检查它。
我再次使用 FOR XML 运行查询并检查计时器。它位于 0:00 并表示查询完成。我再次尝试并立即在 xml 中打开结果，它显示了 11 行 xml 行，其中最后一行是 54,000 个字符。如果您剪切并粘贴表格结果，它确实只显示 2023。时间差异可能是每行中的数据量？有多个具有文本类型的列。
说到文本类型，它使我无法对完整查询执行“计数不同”以提取所有列但根本不发送它们。否则我使用 SSMS 并告诉它丢弃结果。我不确定这是否会影响查询计划。它运行得很快。
我希望让这个东西一瘸一拐地走下去，足以改变它的架构方式。从中长期来看，这根本是不可接受的。
到目前为止，感谢大家的洞察力和帮助。