通过 SQL Server 客户端连接提取数据的速度有多快？

Question

可能的最高吞吐量是多少？有人见过超过 25MB/秒的东西吗？

我一直在试图找出什么是可能的。

我知道有一些调整参数，例如数据包大小、每批行数等，此外，如果通过 TCP，还会涉及开销。我可以以持续 250MB/秒的速度复制文件。我还没有找到任何方法可以通过查询拉取 > 16MB/秒左右的速度。

通过保存到平面文件，我使 bcp 的速度约为 25MB/秒。但是，对于仅从大表（53GB）中进行选择的查询来说，运气不佳。我一直在使用各种版本的 SQL Server、使用最大机器和 SSD 等（32 核、200GB 内存等）在 Google Compute 实例上进行实验

SQL Server 是否有理论上可以在一个连接上处理的最大数量？25MB/秒看起来慢得离谱。

Answer 1

一些值得尝试的事情：

• 更广泛的数据集- 如果您使用狭窄的表（只有几个字段），SQL Server 可能会等待客户端应用程序确认数据并请求下一组行。由于您正在进行实验，请尝试构建一个仅包含两个字段的表：一个标识和一个填充字符串的 CHAR(7000)。
• 直接从缓存中提取数据- 调整虚拟机的大小，使其可以在缓冲池中容纳 32GB 的数据（例如，尝试 64GB 内存），首先将表读入缓存，然后尝试通过网络提取数据。显然，这不是一个实用的长期解决方案 - 但如果您在从磁盘读取数据文件时遇到瓶颈，那么是时候开始调整了。
• 避免中间排序- 尝试使用 SELECT 直接提取表内容，而不是将多个表连接在一起和/或对结果集进行排序。同样，这不是一个实际的解决方案，只是展示如何获得更高的带宽测试吞吐量。
• 首先在本地尝试测试- 这只是有助于排除它不是您用于通过线路提取数据的应用程序或虚拟机之间的网络设置的瓶颈。（此外，客户端 VM 实例上的网络吞吐量也有限制 - 确保您使用的是大型 enoguh 客户端 VM。）如果本地测试运行速度很快，但网络测试很慢，请尝试从客户端本地复制文件VM 到 SQL Server 上的共享驱动器。如果速度很慢，那就是你的问题了。
• 检查您的最高等待类型- 使用sp_BlitzFirst @ExpertMode = 1 ( Github repo ) （免责声明：我是作者），然后查看等待统计部分。如果您将 ASYNC_NETWORK_IO 视为最重要的等待类型，则客户端是瓶颈（或慢速网络）。如果是 PAGEIOLATCH*，则它正在等待从数据文件中读取数据页。