DBA 的 SqlDataAdapter 與 SqlDataReader
與開發人員談論
SqlDataAdaptervs的使用SqlDataReader並閱讀此內容：https ://stackoverflow.com/questions/1676753/sqldataadapter-vs-sqldatareader在解釋從 切換
SqlDataAdapter到對 SQL Server 的影響方面幾乎沒有什麼成果SqlDataReader。我理解
SqlDataReader可能會增加連接對 SQL Server 開放的時間長度，這在有效使用池連接時肯定是一個問題。除此之外，使用
SqlDataReader而不是對SQL Server有什麼影響SqlDataAdapter？有沒有人觀察到此更改對 SQL Server 的影響？
以我的經驗，我覺得
SqlDataAdapter有點像.net，SELECT * INTO #TEMP除了#TEMP在客戶端電腦上。從 SQL Server 讀取整個結果集，不再需要該連接。從 SQL Server 的角度來看，查詢進入、執行和退出。從客戶端的角度來看，整個結果集被載入到客戶端電腦的記憶體中。在讀取大量數據時，這可能會帶來極大的問題。另一方面，我認為
SqlDataReader這是一種cursor打開 SQL Server 連接並SqlDataReader一次提供一行的機制。應用程序可能會在每次讀取之間執行大量工作，這可能會導致與 SQL Server 的連接長時間保持打開狀態。此技術可以允許應用程序處理大型結果集，而無需在客戶端電腦上記憶體整個數據集。
從 SQL Server 的角度來看，兩者之間通常沒有顯著差異。
擔心的是 DataReader 查詢會執行更長時間，因為客戶端將在獲取結果時執行一些工作，而不是將所有結果提取到記憶體中然後處理它們。
但通常即使在使用 DataReader 時，應用程序也會快速處理結果行，並且不會顯著延長查詢的生命週期。對於應用程序來說，按順序處理大型結果集並執行昂貴的工作，這簡直是一件不尋常的事情。即使在確實發生這種情況的應用程序中，它也可能不會經常發生。
在那些確實發生的情況下，這可能是因為不緩衝客戶端上的結果更有效或更方便。將大型結果集複製到客戶端記憶體不是免費的，而且並非總是可行的。
即便如此，在 ASYNC_NETWORK_IO 等待中阻塞會話應該沒什麼大不了的。如果您的查詢計劃涉及假離線結果（通過臨時表或查詢計劃），則任何 S 鎖都將被釋放。但希望您使用的是 READ COMMITTED SNAPSHOT 隔離，並且查詢根本不需要 S 鎖。
如果客戶端獲取緩慢，您可以在 SQL Server 上使用更多並發連接和更多記憶體，但 IMO 並沒有上升到支持有關應用程序應如何讀取數據的一般建議的級別。可以根據具體情況辨識和修復由緩慢獲取引起的任何問題。