[SQL SERVER][Denali] Columnstore Index 執行模式 (Row VS Batch)
很久以前我大概有介紹過Columnstore Index為data warehouse查詢效能上所帶來的改善，
我們知道 SQL2012 多了 Batch 新的執行模式，但當資料量太少時，
執行計畫會選用 Row 執行模式，但查詢時間較短使用 Batch Mode難道就沒幫助嗎?
下面我將實際測試 Columnstore Index 使用 Row 和 Batch 執行模式查詢資料量較少的效能差異。
我將使用 MSDN 上的範例
SELECT c.CommuteDistance,
d.CalendarYear,
SUM(f.SalesAmount) TotalSalesByCommuteDistance
FROM dbo.FactInternetSales as f
INNER JOIN dbo.DimCustomer as c ON
f.CustomerKey = c.CustomerKey
INNER JOIN dbo.DimDate d ON
d.DateKey = f.OrderDateKey
GROUP BY c.CommuteDistance,
d.CalendarYear
一般非叢集索引
時間和I/O統計
執行計畫
實際批次數目=0。
建立Columnstore Index
create nonclustered columnstore index CSI_FactInternetSales on dbo.FactInternetSales
(
[OrderDateKey],
[CustomerKey],
[SalesAmount]
)
再次執行相同查詢
Columnstore Index and Row process
時間和I/O統計
可以看到I/O明顯降低(比使用一般非叢集索引來的好)。
執行計畫
實際批次數目=0。
Columnstore Index and Batch process
由於資料量不夠大(查詢不夠耗時)，所以無法使用 Batch 處理，
但我們還是有辦法可以模擬大資料表，你有想到什麼方法嗎?(千萬不要告訴我...匯入百萬筆真實資料...Orz)，
由於執行計畫資估計的料列數目是透過統計值所取得，所以我們只要在資料表上的統計值動點手腳，
即可讓執行計畫信以為真資料表含有大量資料。
--更新資料表相關統計值=990000
update statistics FactInternetSales with rowcount=990000,pagecount=990000
--刪除執行計畫
dbcc freeproccache
--再次執行查詢
SELECT c.CommuteDistance,
d.CalendarYear,
SUM(f.SalesAmount) TotalSalesByCommuteDistance
FROM dbo.FactInternetSales as f
INNER JOIN dbo.DimCustomer as c ON
f.CustomerKey = c.CustomerKey
INNER JOIN dbo.DimDate d ON
d.DateKey = f.OrderDateKey
GROUP BY c.CommuteDistance,
d.CalendarYear
時間和I/O統計
Batch Mode下，整個邏輯讀取=0。
執行計畫
實際批次數目=129，估計的資料列數目=990000(前面所動的手腳)。
結論:
1.Columnstore Index and Row process 可以享受到資料壓縮和讀取較少行的優點。
2.Columnstore Index and Batch process 可以享受到額外效能的改善和更少的I/O讀取。
參考
