为什么会出现async_network_io等待类型？

上周，我们的数据库发生了一些奇怪的事情。突然，该应用程序对无法保存新实体等的用户阻止了。在查看了SQL Server的活动监视器（带有兼容模式2005的2008）之后，我看到了以下三个条目：

一段时间后，用户获得连接超时。当我杀死进程64时，它们可以再次正常保存。

问题在于，即使有代码可以防止这种情况发生，他们试图在块中保存的实体也多次插入数据库（最多3次）（数字列必须唯一但没有约束） ...检查发生在代码中）。

我们使用实体框架6.0。

• 你们谁知道为什么和何时出现这些ASYNC_NETWORK_IO等待类型，以及如何避免它们？
• 它们到底是什么意思？

ASYNC_NETWORK_IO某种程度上表明客户端应用程序处理结果的速度不如SQL Server提要的结果快。这可能是由客户端应用程序或服务器与客户端应用程序之间的网络连接问题引起的。

请参考Thomas LaRock的帖子

ASYNC_NETWORK_IO等待表明正在发生两种情况之一。第一种情况是会话（即SPID）正在等待客户端应用程序处理结果集，并向SQL Server发送回信号，表明它已准备好处理更多数据。第二个是可能存在网络性能问题。

或Joe Sack的这篇文章

您可能已经知道，ASYNC_NETWORK_IO（在SQL 2005中看到）和NETWORKIO（在SQL 2000中看到）等待类型与调用应用程序相关联，该调用应用程序没有足够快地处理来自SQL Server的结果，或者与网络性能问题相关联。

由于您正在使用entity framework Brent Ozar的这篇文章，可能也很有用

查看这些查询的等待状态，我发现有很多ASYNC_NETWORK_IO-通常为1000毫秒以上。那也没有任何意义！如何用很少的CPU时间和那么少的读取就花费这么长时间来完成查询？这不像应用程序要查询数百万行并且不能足够快地消耗结果。

对于ASYNC_NETWORK_IO等待类型，存在一些误解，主要是因为名称表示网络问题，但是这种等待类型的原因非常少见。

在两种情况下，可能会发生过多的ASYNC_NETWORK_IO等待：

1. 会话必须等待客户端应用程序处理从SQL Server接收到的数据，才能向SQL Server发送信号，表明它可以接受新数据进行处理。这是常见的情况，可能反映了不良的应用程序设计，并且最常见的原因是过多的ASYNC_NETWORK_IO等待类型值。

   这涉及调查导致过多ASYNC_NETWORK_IO等待类型值的应用程序，并经常与创建它的应用程序开发人员进行协调。

2. 网络带宽已用尽。以太网阻塞将导致从应用程序来回传输数据的速度变慢。这本身将降低应用程序的效率。

可以在此页面上找到更多详细信息