在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。

这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……

于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。

还有另一个有趣的事情，对大表的操作DSS查询或DML操作，检查客户的执行计划，无一例外地没有用并行查询或者并行DML，当然，里面会用到很多类似上面的/*+ index(t_xx, idx_xx) */。于是，心里很纳闷，这样跑DSS查询或DML操作，要跑到啥时候才跑完啊？有趣的地方在于，发现了原代码编写者的一个可能的workaround，对大表进行分割分片处理，一次跑不完，我跑它个几百上千次还可以吧。很聪明的做法，不过也感觉到一阵阵深深的无奈。

不可否以地，很多客户有很复杂的业务逻辑要处理，DBA们和开发者们也很聪明地运用着Oracle的技术。编写的代码质量其实也是可圈可点的。不过，在代码实现与现实世界之间，我们却不得不面对一个折衷，优雅的代码，在糟糕的机器配置之前，只能无能为力，于是，过度的调优也就理所当然，顺理成章的成为了主流。

或许，我们的DBA们要主动地进行呐喊；或许，我们还需要有这样的职位，能够从大局上对系统进行规划，包括对系统硬件的容量规划，系统软件实现上的总体设计，最佳实践上的运用等等；或许，也应该是架构师工作的一部分？

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。

我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止。挺好玩的一件事情。这个查询是这样的：

我们要查询在2009年5月份第一个星期在北京市的所有百货超市里最受某一类型的消费者欢迎的前十个商品，这一类型的购物者有以下的购物癖好：购物的时候不买banana。

这个查询其实是基于一个零售业系统，里面存贮着全国所有超市的交易记录，这是一个TB级的数据库。如果有人说他能通过设计索引让这个查询跑得飞快，我可真不敢相信。

这种查询是有可能的，或许某天某位业务经理就跑到你(DBA)面前，帮我查查…，多久能给我结果？你的答案会是分钟，小时，天，还是月呢？

做个类推，中国移动版的:

我们要查询在2009年5月份第一个星期在北京市最受某一类型的手机用户欢迎的前十个热线号码，这一类型的手机用户有以下的癖好：发送的短消息里面从没有出现过类似”I love you”的语句。

或者你可以针对任一个数据库系统构造出类似的ad-hoc查询语句了。

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的实现。