分布式 DBA：使用物化查询表

MQT 和子域

虽然可以为所使用的每个查询谓语定义 MQT（顺便提一下，这并不是一个好主意），但决策支持和数据仓库环境通常包含一组常用的、非常小的、反复执行的查询子谓语和限定符。一种强大但通常被忽略的 MQT 用法是优化对解析此类子谓语的常用的数据子域的访问。

在此场景中，MQT 未包含汇总数据，而是用于帮助 DB2 优化器迅速识别和分离符合条件的行；MQT 用于在一些比较复杂的查询中对行执行预先限定。举例来说，报表系统可以有多个使用 YESTERDAY 数据子域的报表。一个报表可以关注昨天的总体销售，另一个报表可以根据区域来关注昨天的销售，而第三个报表可以根据产品来关注昨天的销售。这三个查询可能共享常用谓语 WHERE DATE = YESTERDAY，它用于立即限制记录集。

如果您创建了三个单独的 MQT 来回答这些查询，则它们需要维护大量磁盘空间。但如果只是创建了一个 MQT 来界定域，比如说 YESTERDAY；则包含在其中的属性不可能会发生改变，比如说 “Region” 和 “Product_ID”；然后对这个 MQT 创建一个适当的索引，关于 YESTERDAY 的所有查询都可以由这个 MQT 来满足。JOIN 和行提取操作是最有可能需要的，但这些操作所使用的数据子集要小很多。

此处的想法很简单：让 DB2 尽可能方便快捷地缩减多个查询中所涉及的数据的大小，而不需要读取多个索引，同时避免创建多个类似的 MQT 以及后续的管理工作。查找查询中的公共模型，考虑它们所表达的域，并确定哪些属性最常用，哪些属性最有可能减小数据大小。然后，为所执行的查询创建一个适当的 MQT，对基本表和 MQT 创建适当的索引，并及时更新统计数据。最后，让 DB2 优化器选择使用基本表还是 MQT；不要在 SQL 中明确引用 MQT。