2010-02-08 65 views
1

我有我的SQL Server上ASYNC_NETWORK_IO大的等待時間,我發現這個有趣的文章C#處理結果集

http://blogs.msdn.com/joesack/archive/2009/01/09/troubleshooting-async-network-io-networkio.aspx

我覺得有趣的部分是:

  • 確定較大的結果集並與應用程序團隊(或開發人員)進行驗證,瞭解它如何被使用。紅旗包括應用查詢較大的結果集,但同時不能處理超過幾行更

如果您收到來自LINQ查詢重新設置,那麼你已經處理它的結果(?) 你會如何每次處理它幾行(?)這意味着一個SQL閱讀器?

如何查找應用程序是否導致 ASYNC_NETWORK_IO問題?

好奇

回答

1

許多開發商往往查詢到的LINQ to SQL較大的結果,然後修剪下來,而不是依靠一個利用IQueryable的,這意味着你正在建設一個更加細化的查詢,而不是細化的數據子集的模式。

您可能會看到這種情況發生:他們只需要一個子集,但他們編碼拉取所有內容,然後將數據過濾到實際需要的數據。

使用IQueryable的存儲庫模式將確保SQL Server服務器的最優化使用,方法是允許開發人員查詢大型結果集並在多個級別修剪它,直到實際需要爲止。到那時查詢不是:

  1. 獲取所有
  2. 獲取數據
  3. 過濾子集
  4. 獲取數據
  5. 濾光片的另一子集
  6. 獲取數據
  7. 顯示

現在:

  1. 從所有應用過濾器,然後另一個過濾器
  2. 獲取數據
  3. 顯示

只是我的想法。

+0

只是一個筆記......他們沒有使用LINQ,這個場景發生。他們可能會拉下整個桌子,以便循環播放,並以編程方式查找他們需要的內容,而不是讓數據庫完成繁重的工作(不正確地預測)。 – AGoodDisplayName 2010-02-08 22:28:11

+0

所以這是例如,select * from big_table 然後在其上實現一個閱讀器,並使用閱讀器或過濾器對foreach進行過濾,而不是使用簡單的過濾器filterparm = 1 – alex 2010-02-09 13:01:47

+0

是的。而不是獲取一切,然後過濾它們,他們應該參數化它,並在數據從數據庫服務器發送到客戶端/ Web服務器之前首先將其過濾掉。 – 2010-02-17 16:37:10