RiCo技術農場

前言

SQL SERVER Indexed View概念和Oracle Materialized View大同小異(應該所有RDBMS都差不多)

那既然都差不多，那為啥還會有領導者和追隨者的區分呢???

差別就在於各家的Optimize(優化器)演算法的好壞，我舉個簡單例子

SQL SERVER中，Sql statement針對複合索引通常以最左邊的欄位為準

如:select * from Emp where first_name='cc' and Mem=100;

而該Table的Index column(id,first_name)，這就讓上述查詢語法不會利用該Index來提高查詢效能，

再來看看Oracle開發團隊為了這問題，加強優化器發展出skip index

進而加強Index可用性和靈活性，同時減輕開發人員和DBA負擔(skip index又會扯一堆，先回歸主題~~XD)。

在真實世界中資料庫大小已發展到T級，面對未來資料只會多不會少的前提下(歷史悠久公司更是如此)

如何讓資料庫軟體極大化應用硬體每一分資源，則是各家開發團隊所追求的目標。

如Indexed View、Partition Table...等(企業版功能)，而這也代表優化器的加強。

不過一項技術發展出來，如果可用性低，限制多、效能差和複雜度高

我想應該沒人會想去了解該技術可以帶來什麼樣的效益

(會不會就是這樣軟體廠商才有錢賺，付費升級版本同時改善~~XD)~~anyway

 

簡介

索引檢視

一般view的資料不會實體存在。 相反它只包含base table的metadata。如果你在view上建立unicluster index，

SQL Server將materialize view中的資料。SQL Server會在更新base table時同步更新indexed view統計資料。

但你不能直接同步index view的內容。在某些方面，indexed view和index非常相似。

indexed view在查詢資料時可以提高效能。它可以降低返回資料所請求的I/O以及執行計算統計值所需的處理時間。

例如，對於OLAP資料查詢或高成本的join來說，利用indexed view可以大大地提高效能。

但相反的降低了修改(insert,delete.update)的效能。

建立indexed view有許多要求和限制，這使得DBA經常放棄使用它。

SQL Server 2008中對indexed view的要求似乎沒有減少。(相關限制可以參考建立索引檢視)

這裡大概說一下，在view上建立的第一個索引必須是unique cluster index。

在view上建立cluster index後，你就可以建立其他的nocluster index了。view必須使用SCHEMABINDING選項建立。

必須使用兩節式命名規則(看來兩節式命名可以提高效率，dbo.mytable會優於mytable)，並在SELECT中明顯指定column的名稱。

當base table被修改時，SQL Server並不重新建立整個索引，它用一種增量的方式來維護index。

當你insert資料時，SQL Server將標識那些資料受影響的行並增加該行的統計值。

所以當你更新base table的資料時，SQL Server會相對應地更新indexed view資料。

當然並不是每每使用Indexed View都可以提高查詢效能(視情況而定)，大致以下條件並不適用

1.Table資料更新異動頻繁

2.所查詢資料原比Base Tabel更大

更多相關資料可以參考MSDN Library設計索引檢視

 

下篇小弟將測試indexed view相關應用