MQT(Materialized Query Table，物化查询表) 物化了涉及一个或多个表或昵称的查询的预先计算结果。而后续的查询可以通过全部或部分匹配 MQT，并由 DB2 来补偿剩余的查询功能，从而达到提高查询性能的目的。本文将会介绍 DB2 中 MQT 匹配的基本原理，并基于此指出如何设计 MQT 从而能使得查询获得更高的匹配率从而提高查询效率。

　　MQT 在 OLAP 场景下能够有效提高复杂查询响应时间，尤其是有下面几类数据操作需求的查询：

　　在一个或多个维度上聚合数据。

　　在多个表之间连接数据。

　　数据来自于一个常见的数据访问子集—也就是该子集会被频繁访问，MQT 能够避免重复计算。

　　MQT 对应用程序是完全透明的。MQT 的相关信息已经被整合进 DB2 SQL 编译器中，它们会判断是否 MQT 应该被用来响应一个完整查询或者查询的一部分。因此，用户可以在不改变应用程序代码的情况下，创建和删除 MQTs，就和创建和删除索引而不需要更改应用程序一样。

　　而如何做到上面的透明性，这是由 DB2 SQL 编译器的 MQT 匹配算法来完成。如果我们把自己作为 MQT 匹配算法的作者，最容易想到的就是 MQT 需要满足以下条件才能够被匹配：MQT 中包含查询需要的所有行 (Record);MQT 中包含查询需要的所有列 (Column);MQT 中行的冗余度与查询结果一致。或者通过某种程度的补偿能够达到上述 3 个条件，那么 MQT 才有可能匹配对应查询。在 DB2 中也是遵循上述基本原理来进行匹配。其大致步骤如下：1) 在查询重写 (Rewrite) 阶段，DB2 编译器会针对目前所有可能被匹配的 MQT 进行分析，并选择一个最优的 MQT 匹配执行方案和不用 MQT 的执行方案。2) 在查询优化 (Optimizer) 阶段，会计算上述两种方案的成本，并选择成本最优的方案作为最终执行方案。需要注意的一点是在第一步中选择最优 MQT 匹配方案是一种启发式的选择 (rule/heuristic based)，并没有真正计算成本。而且在这个过程中，可能匹配的 MQT 数目越多，需要的匹配过程越复杂，对应的编译时间越长。所以说并不是 MQT 越多越好，一方面 MQT 会占用存储空间，同时会增加编译时间。用户需要针对性地创建 MQT，保证其能够真正带来性能上的提升。而匹配的具体算法就不在这里详细阐述。如果读者有兴趣，可以在参考资源 2 中找到具体细节。

　　根据上面介绍的原理，以下 6 种查询可以利用 MQT 来提高性能。

　　MQT 能够精确匹配查询;

　　查询结果集是 MQT 的子集;

　　查询中连接的表数目多于 MQT;

　　查询中连接的表是 MQT 中表的子集，需满足引用完整性 (Reference Integrity, RI);

　　查询中包含 MQT 中不存在的列，需满足功能依赖;

　　查询对应的聚集级别 (aggregation level) 高于 MQT。