带有大varchar列的SQL Server select需要时间加载

我试图运行一个简单的select查询，它在select列列表中有一个名为instructions的列，该列带有varchar（8000）。桌子上有 90000条记录，我的SQLServerManagementStudio控制台花了10秒才返回并显示完整的表数据

SELECT id, name, instructions, etc.... FROM TABLE;

但是，当我从选择列表中删除指令时，执行和显示结果只需1秒。有谁能帮我理解这背后的理论吗

谢谢

---

Keth

这里有一些明显的事情会影响时间，还有一些更微妙的事情。SQL Server的底层存储以及它如何存储/检索这些数据的主题本身就是一本书，其中有很多。（我个人推荐卡伦·德莱尼，但每个人都会有自己的偏好，我很感激我们应该远离主观性）

• 如果您是从服务器以外的另一台计算机连接的，则可能必须通过网络连接编组90k行指令
• SSMS控制台本身必须显示这些，这本身需要时间
• 根据您正在读取的内容与缓冲区缓存以及正在执行的其他查询的大小，您可能会对缓存施加压力，并为整个服务器生成更多的物理IO负载
• 如注释中所述，读取的数据越多，但这是否意味着从磁盘读取的数据越多？这一点在细节上要微妙得多

就磁盘IO问题而言，这取决于指令放置在行中的时间以及数据内联周围列的设置。这可能是因为该行的指令与该行内联存储，这意味着实际上没有额外的磁盘IO来读取它们，而不是不读取它们，更重要的是SQL Server是否费心从内存中的页面解码值

varchar（8000）虽然可能不与其余数据内联，但它可能位于行溢出数据页上，有时称为短大对象（SLOB），在这种情况下，指令字段本身在存储数据的位置存储指针，当您阅读这些指令时，它会导致SQL Server必须每行读取磁盘上其他位置的另一个完全随机的页面（和范围）

根据添加指令的方式/时间，您可能会看到为这些指令分配了大量碎片/缺少连续扩展数据块，尽管这可能与问题无关，但取决于IO子系统

在这一点上有很多未知因素，这使得很难给出任何明确的信息-您处于DB的“视情况而定”区域，这需要更多的细节和调查才能指出特定的原因，而不是上面更一般（但不完全完整）的列表

---

正如Tim Biegeleisen提到的，除非需要，否则不要阅读说明。

从数据库读取更多数据并加载到应用程序中需要更长的时间。这似乎很基本。这是计算机和网络的工作方式。从数据库返回大量文本的90K记录存在延迟（即耗时）。如果您不需要这些说明，那么显然不要选择它们。在SSMS中打开“包含客户端统计信息”并运行这两个查询。一些结果将让您了解客户端显示部分需要多长时间，以及查询返回多少额外数据，这是上面列出的两个因素