[SQL SERVER]What Number of Rows Read

執行計畫中有一個Number of Rows Read資訊,這篇我來簡單介紹一下

之前我在公司分享如何分析和改善執行計畫workshop,

細心的同事有發現到一個新的屬性,就是 Number of Rows Read,這

屬性從SQL 2016開始新增,SQL Server開發團隊提供該資訊,

我個人不得不讚嘆一下,這資訊也是我個人在分析執行計畫需要留意的。

 

Number of Rows Read是什麼

是指該運算子操作讀取的資料筆數,不是指過濾後返回的筆數,

換句話說,和Actual Number of Row完全不同,下圖可以明顯看出差異

我舉一個簡單的例子進行執行計畫分析

SELECT  *
FROM Employee
WHERE NationalIDNumber = 954276278

分析

該查詢使用Clustered index scan存取資料,Number of Rows Read資訊明確告訴我們真正讀取資料的數量共288筆,

而Actual Number of Rows資訊告訴我們QO過濾後的筆數只有1筆,

我再透過一個簡單彙總查詢,相信大家更有感覺這屬性的價值

select count(*) from  Employee

可以看到該彙總查詢使用Index Scan存取資料,Number of Rows Read筆數=288,

和上面Clustered index scan一模一樣(也就是整個資料表所有資料),

但這裡的Actual Number of Rows=288卻大不同,因為該查詢沒有任何過濾條件,

所以QO也會返回整個索引範圍的資料(資料流箭頭相當粗)。

我們在回到Clustered index scan的查詢,我們知道最後的結果集只有一筆資料,

但QO卻使用Clustered index scan讀取了整個資料表288筆資料,

透過Number of Rows Read屬性,我們可以明確知道QO實際讀取和返回的資料筆數,

這很明顯就是一個效能低落的查詢,所以,我們必須改善這查詢,如以下執行計畫

最後的結果集只有一筆資料,我們當然希望QO透過高效率的索引搜尋快速定位該筆資料即可,

換句話說,Number of Rows Read=1才是我真正想要的,

現在,我想你應該知道這屬性所要表達的潛在問題了吧。

 

P.S:更多的執行計畫分析和改善,我將在第三部曲決戰執行計畫,幫大家更了解執行計畫