執行計畫中有一個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:更多的執行計畫分析和改善，我將在第三部曲決戰執行計畫，幫大家更了解執行計畫
