SQL Server 2017 CU18较CU3在Linux下Update/Insert性能大幅下降求助

我确实见过不少用户在Linux环境下升级SQL Server 2017的累积更新（CU）版本后，遇到过类似的ADO.NET客户端执行Update/Insert时性能暴跌的问题，尤其是从较早的CU版本（比如CU3）升级到CU18这类较新的版本时。结合你给出的测试细节——服务器端查询存储耗时无变化，仅C#应用内的总耗时大幅增长，我来分析下可能的核心原因：

可能的原因分析 #

1. TDS协议交互或网络栈的版本差异 #

SQL Server 2017从CU3到CU18的迭代中，微软对Linux版的网络栈和TDS（表格数据流）协议处理逻辑做了不少调整。查询存储统计的是纯服务器端执行时间，而你在C#里的计时包含了：

• 客户端参数打包发送到服务器的时间
• 服务器处理请求并返回响应的时间
• 客户端接收响应并完成ExecuteNonQuery()回调的时间

如果CU18引入了额外的TDS校验步骤、数据包拆分逻辑变化，或者Linux网络线程模型的调整导致上下文切换增加，都会让客户端与服务器之间的往返交互耗时变长——这部分时间不会体现在查询存储的统计里，但会显著拉高C#应用的总计时。

2. ADO.NET驱动与SQL Server CU版本的兼容性问题 #

你提到使用的是纯ADO.NET（无EF），如果用的是旧版的System.Data.SqlClient驱动，可能和CU18的SQL Server存在兼容性适配问题。比如CU18可能新增了某些TDS协议特性，旧驱动在处理这些特性时需要额外的解析逻辑，导致客户端侧的处理耗时增加。

3. 参数传递或执行计划缓存的隐性变化 #

虽然查询存储显示执行时间一致，但CU18可能调整了参数化查询的缓存逻辑。比如某些情况下，CU18会强制重新生成执行计划的前置检查步骤，这部分时间发生在服务器端执行查询之前，但查询存储可能没有统计到这部分等待时间——而客户端会等待整个流程完成，所以总耗时被拉长。

排查建议 #

• 升级ADO.NET驱动：尝试替换为最新的Microsoft.Data.SqlClient驱动（微软现在主推的SQL客户端库），看是否能消除版本兼容性带来的性能损耗。
• 调整连接字符串参数：测试修改Packet Size（比如设置为8192或16384）、关闭加密（Encrypt=False，如果不需要加密的话），观察是否能优化网络交互耗时。
• 抓包分析TDS流量：用Wireshark等工具对比CU3和CU18下的TDS数据包，看两者在数据包数量、大小、交互次数上是否有明显差异，定位是哪一步的交互变慢了。
• 检查SQL Server日志：查看CU18服务器的错误日志，是否有网络相关的警告或异常，比如连接超时、线程池不足等信息。

内容的提问来源于stack exchange，提问作者Thomas853