Materialized Views, 其实不是View。我觉得把它归类于Index可能还准确一些。

View在我们的印象里总是逻辑存在的。即使前面加上一个Materialized，我们只会觉得奇怪，干嘛要对View进行物化呢？

把它理解为一种特殊的Index未尝不可，况且，它与Index有一些相同点：

• They consume storage space.
• They must be refreshed when the data in their master tables changes.
• They improve the performance of SQL execution when they are used for query rewrites.
• Their existence is transparent to SQL applications and users.

而一般的View呢？

• They don’t consume storage space.
• They don’t need to be refreshed when the data in their master tables changes.
• They don’t improve the performance of SQL execution, database just maps the View to the underlying Table when executing.
• Their existence is transparent to SQL applications and users.

不过，Materialized View为什么特殊，我觉得在于它的应用场合——数据仓库。或许我们可以说，Materialized View 是专门用于数据仓库的Index。

问题在于，数据仓库场合和OLTP场合对Index的要求有哪些不同，干嘛需要一个专门的Materialized View？

数据仓库的查询一般都是”大”查询。何谓大？多表联合（n个大表join在一起），多维度分析（一长串的group by），聚合统计（avg, count, sum,rank,cube）。

数据库如何跑这种查询呢？硬件方面，用更多的CPU和硬盘；软件方面，采用数据分区，并行执行。软硬件一起提供的厂商，如Oracle的Exadata, Teradata, Netezza, 可能做到数据库软件与硬件的紧密结合，从而实现对数据的智能扫描（在IO这一层实现对不需要数据的过滤）等技术。

这种做法可以很好地应对数据仓库里一类重要的查询：随机查询。例如，某位领导突然想到了一个决策方案，开发人员必须为这种决策提供分析数据。

另一方面，如果某类“大”查询经常被执行，我们就得想办法对其进行优化了。最直接的方法就是缓存中间结果，多表连接的结果，多维度分析的结果，聚合统计的结果，对了，这就是Materialized View的用武之地了。

Materialized View缓存了中间结果，Oracle通过Query Rewrite的技术把对基表的访问转换成对Materialized View的访问。这个对性能的提高可以是成千上万倍的。

如何创建Materialized View以便让Query Rewrite用到，这也许是Materialized View里面最重要的部分，也是理解Query Rewrite如何工作的一个途径。最好的参考文献当然是Oracle的Oracle® Database Data Warehousing Guide.

以后的文章再回来看看Query Rewrite的实现。