零，ASYNC_NETWORK_IO 的概念
ASYNC_NETWORK_IO 等待類型是DBA經常會遇到的，雖然名稱是異步、網絡和IO，但是大多數情況下，此等待類型跟任何網絡問題均無關系。
數據庫系統大量出現ASYNC_NETWORK_IO等待的情況，大致有兩類：
- 會話必須等待客戶端應用程序處理從SQL Server接收到的數據，才能向SQL Server發送信號，表明它可以接受新數據進行處理。 這是最常見的情況，可能反映了不良的應用程序設計。
- 網絡帶寬已用盡， 以太網阻塞將導致從應用程序來回傳輸數據的速度變慢，這將降低應用程序的效率，這種情況不常見，可以說是罕見。
一，客戶端應用程序的問題
當SQL Server大量出現ASYNC_NETWORK_IO等待時，最常見的原因是客戶端應用程序無法足夠快速地處理從SQL Server傳回的數據，換句話說，就是SQL Server傳遞給應用程序的數據量超出了應用程序的處理能力。常見於客戶端應用程序請求大量的數據。
當應用程序請求大量的結果數據集時，緩慢的數據處理將導致數據緩沖區被填滿，從而阻止SQL Server向客戶端發送新的數據。當緩存區被填滿時，執行批處理的服務器進程（SPID）將被迫等待，直到客戶端應用程序設法開始處理緩沖區中存儲的數據，從而允許SQL Server將新的結果集（通過緩沖區）發送給客戶端。在等待將應用程序請求的新數據發送到緩沖區以進行進一步處理時，SQL Server會生成ASYNC_NETWORK_IO等待類型。
二，如何減少ASYNC_NETWORK_IO等待？
在遇到高 ASYNC_NETWORK_IO等待類型時，DBA應該如何減少此等待？
1，發送小數據集
DBA需要調查導致出現ASYNC_NETWORK_IO等待類型的應用程序，並與創建應用程序的開發人員進行協調。
- DBA需要檢查應用程序是否從SQL Server實例請求大數據集，然后在客戶端做過濾。
- 改進的方法只有一個：把過濾放到請求數據時，在SQL Server中執行過濾，向客戶端應用程序發送小數據集。
2，使用共享內存
在SQL Server端加載大數據時，也可以通過設置啟用共享內存協議（Shared memory protocol ）來降低ASYNC_NETWORK_IO等待類型。
SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID;
在客戶端應用中，使用net_transport=’Shared memory’來連接數據庫。
3，網絡問題
如果檢查了以上內容之后，SQL Server的ASYNC_NETWORK_IO等待類型出現的次數並未明顯減少，那么可能是網絡的問題。
檢查SQL Server和客戶端之間的網絡帶寬，網速慢是ASYNC_NETWORK_IO等待值較高的常見原因。
【總結】ASYNC_NETWORK_IO 等待思路
此等待狀態出現在SQLServer已經把數據准備好，但是網絡沒有足夠的發送速度跟上，所以SQLServer的數據沒地方存放。
- 出現這種情況一般不是數據庫的問題，調整數據庫配置不會有大的幫助。
- 網絡層的瓶頸當然是一個可能的原因：對此要考慮是否真有必要返回那么多數據？
- 應用程序端的性能問題，也會導致SQLServer里的ASYNC_NETWORK_IO等待。如果見到了這個類型的等待，就要檢查應用程序的健康狀況，也要檢查應用是否有必要想SQLServer申請這么大的結果集。
- 程序返回結果集的方式 。
參考文檔：