注:以下的試驗在多人共享的開發測試服務器上也可以進行,因為實際上可以分別看到某個表所占用的內存情況。但為了方便,筆者在做此試驗時,在一個單獨的、確認沒有其它并發任務的數據庫上進行,因此所看到的內存變化正是每一次所執行的SQL語句引起的。
我們首先來看一個簡單的實例。創建下表:
以下是引用片段: Create Table P_User ( UserMobileStatus int NOT NULL, MobileNo int NOT NULL, LastOpTime DateTime Not NULL ) |
然后為該表插入一定的數據:
以下是引用片段: Declare @i int Set @i=28000 WHILE @i<29000 BEGIN Insert Into P_User Select @i % 2,@i,GetUTCDate() Set @i=@i+1 END |
然后我們在查詢分析器中首先執行:
以下是引用片段: Set Statistics IO ON |
并按下Ctrl+M以顯示實際的執行計劃。
此時,可以開始進行我們的試驗了。為了準確觀察每一次SQL語句變化情況,在執行第一條SQL語句以前,我們首先清空SQL Server所占用的數據內存:
以下是引用片段: CHECKPOINT GO DBCC DROPCLEANBUFFERS |
這將清空SQL Server所占用的數據緩沖區(此語句在生產服務器上慎用,因為將導致一段時間內后續的SQL語句執行變慢)。
4.2 執行高選擇性選取
執行如下的SQL語句:
以下是引用片段: Select * From P_Order A Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo Where A.MobileNo=28913 |
在兩個表都沒有任何索引情況下,兩張表都將執行全表掃描。要讀入所有的數據頁到內存??傮w邏輯讀取決于兩表的數據頁數。
在一個表有聚集索引或者非聚集索引情況下,該表將執行Index Seek,另一個表將出現全表掃描。內存數據緩沖區中,將有一張表只讀入最終數據所在的數據頁、一張表讀入全部數據頁。邏輯讀數取決于表在聯接中的秩序、以及無索引表的數據頁數。
原文轉自:http://www.anti-gravitydesign.com