本地SQL Server读取Azure Blob数据文件的单线程性能异常排查问询

1. 为何顺序执行无法实现更快读取？ #

这主要和SQL Server单线程I/O机制以及云存储的带宽特性有关：

• SQL Server单线程查询依赖**预读（Read-Ahead）**批量拉取数据，但单线程下预读的并发请求数非常有限——默认预读按64页（256KB）的批次发起，而云存储（尤其是对象存储）的单请求带宽通常有上限（比如部分厂商单流上限30-50Mbps），单批次的数据量不足以跑满你的网络链路。
• 云存储的带宽是并发聚合型的：单线程只能发起单个读请求，没法利用云存储的多流并发带宽配额；而多线程可以同时发起数十个读请求，把分散的单流带宽叠加起来，自然能接近500Mbps的预期值。
• 远程存储的网络延迟会放大单线程的瓶颈：SQL Server单线程需要等待上一批次的I/O完成才能发起下一次请求，往返延迟会持续占用线程时间，进一步限制了带宽利用率。

2. 单线程是否存在最大读取性能限制？ #

是的，而且是多层级的限制：

• SQL Server层面：单线程查询的预读并发度由全局预读线程池控制，无法独占足够的预读资源；同时，单线程的CPU处理能力也会制约I/O请求的发起频率——即使网络能扛，线程也可能忙不过来处理I/O回调。
• 网络栈层面：单TCP连接的带宽受限于TCP窗口大小和延迟带宽乘积（BDP）。如果你的云存储跨区域部署，延迟较高，默认TCP窗口无法容纳足够的待传输数据，会导致单流带宽上不去。
• 云存储层面：几乎所有云厂商的对象存储都对单个请求的带宽做了限制，目的是防止单个用户占用过多资源；单线程只能依赖单请求，自然触碰到这个上限。

3. 查询为何未自动启用并行执行，通过多线程读取同一数据文件提升性能？ #

这是SQL Server 2016的成本估算模型和并行触发逻辑导致的：

• 成本阈值不匹配：SQL Server默认的Cost Threshold for Parallelism（并行成本阈值）是5，但这个阈值是基于本地磁盘I/O的成本估算的。云存储的I/O延迟远高于本地磁盘，但SQL Server的成本模型并没有识别到远程存储的特性，依然把I/O成本算得很低——你的简单SELECT查询，在SQL Server眼里“成本不够高”，所以不会触发并行。
• 强制并行提示的局限性：你用的OPTION(QUERYTRACEON 8649)和OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'))虽然能强制生成并行计划，但有前提：
  • 如果你的查询是简单的单表扫描且无复杂运算，SQL Server可能认为并行的调度开销（线程创建、数据合并）超过了收益，最终还是选择串行计划；
  • 检查全局MAXDOP设置，如果服务器的MAXDOP=1，即使强制并行也不会生效；
  • 表的统计信息过时，导致SQL Server误判数据量大小，认为不需要并行。
• 数据文件拆分无效：拆分数据文件主要是为了利用多磁盘的I/O并行，但你的数据都存在云存储的同一个账户下，拆分文件并不会增加云存储的并发读能力——云存储的并行是基于请求数，不是文件数。

几点建议 #

• 优化本地网络栈：调大TCP窗口大小（通过注册表或组策略修改TcpWindowSize），适配远程存储的延迟，提升单流带宽；
• 调整并行阈值：把Cost Threshold for Parallelism调低（比如设为1），让SQL Server更容易触发并行；同时检查MAXDOP设置，确保允许并行执行；
• 云存储侧优化：联系云厂商确认单流带宽限制，看是否可以调整；或者将数据存储到支持更高单流带宽的云块存储（而非对象存储）；
• 强制并行的补充：尝试结合OPTION(MAXDOP n)指定并行度（n为CPU核数的一半），配合QUERYTRACEON 8649一起使用，可能会生效。

内容的提问来源于stack exchange，提问作者Jānis