這可能是一個愚蠢的問題，但我試圖瞭解當從SQL Server中檢索數據時在封面下發生了什麼。假設我們從索引視圖中選擇數據以消除模糊性。如何從SQL Server返回數據
所以我的理解是，查詢優化器會將此同一個表。好的，但是在被調用的視圖和返回給客戶端的實際數據之間發生了什麼？數據是從SQL Sever中的物理文件結構中檢索的，並且我假設它會返回到調用客戶端時發生某種流式傳輸？中間的步驟是什麼？
現在讓我們來比較直接在服務器與一些遠程客戶端上的某個地方調用這一觀點。數據如何返回到遠程客戶端？我們假設這是通過ODBC，但SQL Server本身是否以相同的方式返回數據，而不考慮傳輸？那麼，它是否會檢索結果，然後將這些結果傳遞給客戶端，還是將它們以某種方式通過傳輸機制進行流式傳輸？
我希望這是有道理的。預先感謝任何啓示！ :-)
是的......
我會用ODBC來說明。它基本上是一個'界面'。你通過一個ODBC驅動程序與SQL服務器通信，它將ODBC轉換爲SQL服務器並將sql服務器轉換爲odbc，sql服務器不會做任何不同的事情。
同樣要求你的數據通過TCP/IP客戶端PC上或觸發器內不會改變查詢優化器是如何計算出做什麼或如何底層的數據從磁盤中讀取。
良好的軟件設計的關鍵部分是模塊化。這個位與磁盤系統進行通信，這個位優化，這個位向下發送數據到一個套接字。
不要嘗試，並涉及該磁盤驅動器上的這些位是如何被該死的困難最終成爲這個顯示器上這些像素，放在一邊，它否定編程作爲一個解決問題的方法。
感謝您的回覆。我試圖找出直接返回數據與通過網絡返回數據之間的性能差異。延遲時間最長以及影響程度如何。假設該視圖返回了數千條記錄，我們是否會開始在服務器上獲得某種類型的緩存，然後再等待網絡上的延遲，因此這會使成本變得微不足道？只是試圖量化這一些如何。 –
寶貴的但並非真正與SQL Server有關的事情，它也將嚴重依賴於你的網絡繁忙程度。服務器方面，你所能做的就是玩多少數據/多少次以及你走哪條路，這又取決於網絡的建立方式。規則客戶端服務器之一是，如果你可以在服務器上這樣做。如果你正在盡力而爲，並且希望將操作委託給客戶端，那麼無論如何它都不是時間關鍵。 –
要覆蓋如何檢索數據的區域，當您調用SQL來檢索某些數據時，SQL將首先檢查您要查找的數據頁是否在內存中以加快數據。如果沒有，那麼它將從磁盤上的數據文件中檢索這些數據並將它們讀回到內存中。從那裏你的數據被提交給客戶端。在一個視圖的情況下，這是一個只有一個強調的SQL語句構建這個視圖的對象。因此，將執行此語句以構建視圖，然後將評估傳遞給視圖的任何謂詞並將其傳遞給客戶端。
對於如何將數據傳送到客戶端，這將取決於如果服務器監聽通過TCP/IP（這是最常見的），命名管道，共享內存。在ODBC方面，SQL將把數據傳遞給ODBC驅動程序，並將數據封裝在TCP/IP數據包中，並將其傳送到客戶端，無論您連接的是何種端口（SQL默認爲1433）。
希望這會有所幫助。
當一個查詢被髮射到執行它最終將開始產生效果，一次一行。無論是從表，從索引視圖，從表構造器表達式或其他任何查詢。最終將達到一個階段，它將準備好結果行，並且需要將其發送給客戶端。 Tabular Datastream Protocol specifications描述了「發送」發生的格式。使用的協議（套接字，網管，共享內存）無關緊要，所有協議下的格式都是一樣的。客戶端驅動程序全部實現TDS流的解析，然後將TDS格式的數據轉換爲適當格式的客戶端API。如果是ODBC，則當調用SQLBindCol時，數據將移動到列綁定中指定的緩衝區中。 OleDB客戶端將通過DBBINDING結構指定內存區域。受管理的SqlClient應用程序沒有指定綁定，因爲管理的內存管理不同，並且避開指針，而是SqlClient自身將數據複製到對象中，然後在調用SqlDataReader.GetValue時返回對象。由於客戶滿意地檢查行值，他們稱之爲API的版本NextRow（IRowset::GetNextRows，SQLFetch，SqlDataReader.Read等），直到API返回「沒有更多行」。
從服務器返回到客戶端的這種封送處理將繼續，直到生成併發回所有行。如果客戶端延遲處理很長時間（停留在處理一個值並且沒有調用PAI的味道NextRow），那麼最終transport flow control開始並且服務器將以ASYNC_NETWORK_IO等待類型阻塞，直到客戶端恢復迭代結果並放開運輸流量控制。以某種方式相關的討論是Speeding up the rate that IIS/.NET/LINQ retrieves data from the Network Buffers。
你的問題有很多領域，它涵蓋。數據返回客戶端的方式主要取決於您選擇使用的遊標，但它也可以基於傳輸機制進行更改。我不是這方面的專家，我知道兩方面都相當好，但不是中等。我只知道它的工作原理。 :) –
引擎中有很多東西可以提供正確的數據，因爲索引構建和分析可以加載預編譯的視圖結構;你的問題可以從網絡工程師那裏得到很好的答案，它可以解釋數據如何傳輸，本地和遠程，協議，層和模型。這非常有趣，但有點複雜，因爲它混合了不同的領域。 – Hamikzo
「從索引視圖中選擇數據以消除歧義」我懷疑索引視圖沒有做到你認爲它正在做的事。 – Hogan