当通过 Internet 连接上的 Sql Server Management Studio 连接到客户托管服务时，如果该连接上还有其他活动，则 Sql Server 与托管服务的连接通常会断开。
解决这个问题的一个明显的方法是不要在连接上有额外的流量，但仍然引出一个问题“为什么 Sql Server 连接如此不稳定？”。
假设有 100kb 的带宽，并且有几个下载任务正在运行，每个任务的带宽为 35kB，那么就有 30kB 的带宽空闲容量。如果启动了第三个下载任务，服务器可以以 35kB 的带宽提供服务，那么下载任务的带宽上限将为 30kB，剩余的带宽为零。这很好，所有下载任务都运行良好。
但是，对于 Sql Server 连接来说，是否有空闲带宽似乎并不重要。即使我有 1024kB 空闲带宽容量，如果连接上有任何其他活动，Sql Server 也会定期超时。多年来，不同的客户托管服务提供商都遇到过这种情况，因此假设它与 Sql Server 有关。
为什么 Sql Server（显然）需要独占访问互联网连接才能维持连接......即使该连接具有超出连接上的任何额外活动的大量备用容量？
答案1
我认为这听起来确实像是 SQL Server 问题，但如果您遇到连接超时，则很可能与带宽无关，而与服务器上的连接内存有关。除非您有自己的服务器，否则您将受制于其他访问该 SQL 实例的应用程序。要么有人保持连接打开，要么服务器缓冲区超载。查询超时显然是另一回事。除非主机编写了一些棘手的脚本，否则一次可以建立的连接数是有上限的。
或者，也可能是 TCP 数据包在防火墙等线路的某处丢失，或者只是互联网连接不良。
排除所有本地问题（您的互联网连接、您的连接字符串等），我会尝试与您的主机合作来解决这个问题，因为这可能是他们有责任修复的问题。
答案2
下载是单个 TCP 连接吗？如果是种子，那么就不再是 35kb vs 30kb vs 30kb 的简单问题，而是 1 个 SQL 服务器连接 vs 500 个其他连接