DB2 中 MQT 的匹配原理及使用技巧

核心提示： 关键字 DETERMETED BY 准确地表达了函数依赖的含义；NOT ENFORCED 表示在执行增删改时 DB2 并不验证数据来保证约束的完整性；ENABLE QUERY OPTIMIZATION 告诉编译器可以利用这个函数依赖来重写和优化查询，由于 DB2 并不强制函数依赖的这种约束的完整

关键字 DETERMETED BY 准确地表达了函数依赖的含义；

NOT ENFORCED 表示在执行增删改时 DB2 并不验证数据来保证约束的完整性；

ENABLE QUERY OPTIMIZATION 告诉编译器可以利用这个函数依赖来重写和优化查询。

由于 DB2 并不强制函数依赖的这种约束的完整性，根据这个函数依赖优化的查询结果可能是错误的，因此，需要注意函数依赖的定义和维护。

继续 MQT 匹配的讨论。我们知道，MQT 匹配时，要求查询中需要的列都能从 MQT 中找到。那么如果查询中包含 MQT 不存在的列呢？函数依赖让这种匹配也变成可能。DB2 根据这些函数依赖重写查询，通过 MQT 和基本表的 re-join 来获得 MQT 缺少的列。

在清单 6 的例子中，MQT SALES_BY_CAT 的定义包含列 CAT_ID，统计每类产品的销售总量，然而查询却希望获得 CAT_DESC 和销售总量，而 CAT_DESC 不在 MQT 中。如果没有函数依赖，这个 MQT 是不能匹配的。而正是 Product 上的函数依赖 CAT_ID -> CAT_DESC 让这个 MQT 的匹配变成可能。

拓展诊断信息 (Extended Diagnostic Information) 段揭示了编译器的整个处理过程：诊断信息 1 中 EXP0073W 说明由于查询中包含 MQT 没有的列，这个 MQT 不能匹配；诊断 3 中 EXP0149W 表示当编译器收集到函数依赖后，用 MQT 匹配了这个查询。优化后的语句和执行计划一致的显示 MQT 的匹配以及 re-join 操作的生成。

由于 CAT_ID 不是具有唯一性的键，优化后的语句中利用 DISTINCT 来去除重复，对应了查询计划的 SORT 操作。一般情况下，这个 DISTINCT 是作用在维表上，开销很小。

清单 6. 含有额外 RI-Join 时的 MQT 匹配

　--MQT　missing　columns,　with　FD　
　CREATE　TABLE　MQTSCH.SALES_BY_CAT　AS　
　(SELECT　CAT_ID,　SUM(AMOUNT)　AS　TOTAL,　COUNT(*)　AS　CNT　
　FROM　MQTSCH.PRODUCT　P,　MQTSCH.SALES　S　
　WHERE　P.PROD_ID　=　S.PROD_ID　
　GROUP　BY　CAT_ID　)　
　DATA　INITIALLY　DEFERRED　REFRESH　IMMEDIATE;　
　
　refresh　table　MQTSCH.SALES_BY_CAT;　
　runstats　on　table　MQTSCH.SALES_BY_CAT;　
　update　syscat.tables　set　card=10　where　tabname='SALES_BY_CAT';　
　
　--collect　the　explain　information　
　DELETE　FROM　EXPLAIN_INSTANCE;　
　explain　plan　for　SELECT　CAT_DESC,　SUM(AMOUNT)　
　FROM　MQTSCH.PRODUCT　P,　MQTSCH.SALES　S　
　WHERE　P.PROD_ID　=　S.PROD_ID　
　GROUP　BY　CAT_ID,　CAT_DESC;　
　
　!db2exfmt　-1　-d　mqtdb　-o　fd.plan;