我們首先來看一個簡單的實例。創建下表:
以下是引用片段: 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語句執行變慢)。
眾所周知,SQL Server執行SQL語句的性能判定標準主要是IO讀取數大小。本文在不違反這一原則情況下,同時來分析一下部分SQL語句執行時,SQL Server內存的變化情況。
首先簡述一下SQL Server內存占用的特點。SQL Server所占用的內存除程序(即SQL Server引擎)外,主要包括緩存的數據(Buffer)和執行計劃(Cache)。SQL Server以8KB大小的頁為單位存儲數據。這個和SQL Server數據在磁盤上的存儲頁大小相同。當SQL Server執行SQL 語句時,如果需要的數據已經在其內存中,則直接從內存緩沖區讀取并進行必要的運算然后輸出執行結果。如果數據還未在內存中,則首先將數據從磁盤上讀入內存Buffer中。而我們通常評價SQL性能指標中的IO邏輯讀取數對應的正是從內存緩沖區讀取的頁數,而IO物理讀取數則對應數據從磁盤讀取的頁數。
注:以下的試驗在多人共享的開發測試服務器上也可以進行,因為實際上可以分別看到某個表所占用的內存情況。但為了方便,筆者在做此試驗時,在一個單獨的、確認沒有其它并發任務的數據庫上進行,因此所看到的內存變化正是每一次所執行的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語句執行變慢)。
眾所周知,SQL Server執行SQL語句的性能判定標準主要是IO讀取數大小。本文在不違反這一原則情況下,同時來分析一下部分SQL語句執行時,SQL Server內存的變化情況。
原文轉自:http://www.anti-gravitydesign.com