简介
MQT（Materialized Query Table，物化查询表） 物化了涉及一个或多个表或昵称的查询的预先计算结果。而后续的查询可以通过全部或部分匹配 MQT，并由 DB2 来补偿剩余的查询功能，从而达到提高查询性能的目的。本文将会介绍 DB2 中 MQT 匹配的基本原理，并基于此指出如何设计 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 中找到具体细节。
2 3 4 5 6 下一页</div> </div> </div> </div> </div>