Indexed View是由data warehouse中的概念，當初就是為了提高查詢效能而產生的技術
而該技術同樣也只有企業版才有支援，就讓我們來體驗所帶來的神奇效果。
前言

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更大

關於Indexed View小弟就介紹到這裡，如果你想知道更詳細的資料
可以參考MSDN Library設計索引檢視，
下一篇我將測試Indexed View為我們帶來那些的改善。