我们在Win2k3 R2上有一个SQL Server 2005（64位标准）。 我们看到ASYNC_NETWORK_IO的数量不成比例（看起来）会导致数据库不可用，这会减慢或挂起面向客户的（dynamic生成的，依赖数据库的）网站。
我们有理由相信，这些等待是由缓慢/未优化的后端应用程序引起的 – MS Access表单和ASP页面对大量数据提出大量请求，但不会足够快地消耗结果。 显然，优化或replace违规应用程序是有意义的，并且/或者将它们分开，这样它们就不会经常低效地敲击网站的数据源。 我们正在做这些事情，但这非常耗时。
与此同时，我正在寻找一种临时/短期的缓和方式，而且我遇到了这个有用的文章 ，从中我收集到的ASYNC_NETWORK_IO等待实际上是一个networking缓冲区问题：如果客户端没有足够快地使用数据， SQL Server的networking缓冲区填满，服务器变得不可用。
所以：我们可以简单地增加networking缓冲区大小，即使淘气的应用程序运行缓慢，SQL Server仍然可用的网站？
如果是的话，我们该怎么做？ 对于我的生活，我找不到任何资源，说如何增加networking缓冲区大小。 我不知道这是否是NIC问题，Windows问题或SQL Server特定的问题。 （我们不是内存或磁盘空间不足，在硬件/金钱问题上也不错。）
如果没有，那么短期内任何其他的build议，而我们正忙于重写所有的旧代码，将不胜感激。
提前致谢 … ！
是的，async_network_IO等待通常是应用程序占用大量数据的一个症状，而只是真的需要一点点。 networking上的问题是传输的来回性质。
你提到的ASP – 如果这是传统的ASP，这往往有循环通过logging集的发展问题 – 这是缓慢的。 正确的做法是使用getrows，它将数据一个接一个送到应用程序（web）服务器而不是来回。