Server在表结果集中缓慢地传输结果，但使用XML立即传输结果

Question

我有一个查询，它离开了联接100+表并返回2,000+列，但只有几行(10-20行)。这个部分目前不在我的控制范围之内，它过去运行正常，列数较少(可能在正常的非宽表宽度下)。在编译初始计划之后，执行是“即时”的，而且我实际上没有将所有结果返回给客户端。如果我返回1行，它是即时的，并立即返回结果。

这是当我返回所有的11个左右的结果，它下降到大约15秒。但是，如果我添加任何"FOR [原始元素，XSINIL]“迭代，它也会立即返回所有结果加上XML开销。据我所知，这排除了查询的实际执行，并将其隔离到正在计算的查询结果和发送给客户端的查询结果之间。

我已经找了大约4天的时间来解释这件事。有什么方法可以通过结果集获得XML的速度吗？它为什么要这么做？

在2008R2和2016上尝试了TCP/IP和命名管道

更新

根据反馈，对于表格的结果，发生的是第一次，大约需要20秒。SSMS中的计时器一直运行到大约11秒，然后停止。然后，当显示结果时，计时器跳到20秒。下一次运行定时器时，计时器挂起，当显示结果时，计时器会弹出大约9-11秒。

通过将主表的唯一id与表函数连接起来来选择11行的方式。我尝试用临时表替换表函数。为了选择一条记录，我基本上将数据传递到表函数中，从而得到一个结果。我还尝试使用一个直的id =文字数字。对于这些，计时器甚至不会在显示结果之前留下0。

我不能“插入”临时表，因为普通表的列太多了。我也不能在上面创建一个索引视图来检查它。

我再次使用FOR运行查询，并检查计时器。它位于0:00，并表示查询完成。我再次尝试并立即打开xml中的结果，它显示了11行xml行，其中最后一行为54,000个字符。如果您剪切并粘贴表格结果，它实际上只显示2023。时间差异可能是每行的数据量吗？有多个具有文本类型的列。

说到文本类型，它使我无法对完整的查询执行“计数不同”的操作，以提取所有列，但根本不发送它们。否则，我使用SSMS并告诉它放弃结果。我不确定这是否会影响查询计划。它跑得很快。

我希望能让这个东西一瘸一拐地前进，足以改变它的架构方式。从中长期来看，这是不能接受的。

感谢大家到目前为止的洞察力和帮助。

Answer 1

这听起来像是ADO.Net在构造数据集以供在应用程序中使用时的开销。在返回XML的单个列后，这一开销是不必要的。

你的情况相当极端--这是很多专栏要处理的。所以我想说，坚持使用XML！