我们在[1]和[2]中描述了如何从一个MV中计算出Query的结果，并且我们提到匹配算法是作为优化器的一个Rule执行的。通常在一个数据库中用户会创建或者维护多个MV来加速查询，每个 Query跟每个MV来做匹配会极大地降低查询优化的速度，因此我们需要提前过滤到完全不会匹配上的MV以加速查询过程。

Lattice Index

假设我们有一些节点，每个节点都是元素的集合。我们定义如下2个关系：

1. $minimum\ superset$: $V_1 \sub V_2$并且$\not\exist V_i, where V_1 \subset V_i\land V_i \subset V_2$
2. $minimum\ subset$: 跟1的定义相似。

我们可以将这些互为$minimum\ superset$的节点用线连接起来，从而形成一张图。如下是一个例子：

SPJG的过滤条件

有了lattice index，我们可以通过[3]中提到的一些条件快速过滤掉不匹配的MV。

1. MV的base table集应该是Query的超集。根据这个条件，我们可以把每个MV视作一个节点，里面的元素是base table集，从而构建lattice index。在这个index中我们从tops开始查找，直到Query的base table不被某个节点包含即停止。
2. 在[1]中提到我们可以将MV中的base table按照cardinality reserving join构建一张图，并且依次按条件删除边和点，直到没法再删了为止。最后留下的图的base table集我们称之为hub。显然如果一个Query能从MV中计算出来，那么这个MV的hub必然是Query的base table的子集。因此我们以每个MV的hub作为集合来构建lattice index，然后搜索的时候从roots出发即可。
3. 假设SJPG 的grouping或者projection里直接使用了某个列，那么MV的output的列表里应该包含这个列，并且这里应该考虑到column equivalence class。比如我们的Query需要的列是$\{A, B, C\}$，而Query里column equivalence class是$\{A, D, E\}, \{B, F\}, \{C\}$。而MV的column equivalence class是 $\{\underline{A}, D, G\}, \{\underline{E}\}, \{\underline{B}\}, \{\underline{C}, H\}$，其中下划线的是输出列。那么MV的extended output是$\{A, D, G, E, B, C, H\}$。我们以MV的extended output作为节点的集合来构建lattice index。在搜索的过程中从tops开始，直到找到不匹配的节点。注意这里的匹配不一定是列完全匹配，只需要Query的每个列的column equivalence class里有一个列匹配即可。
4. 最后我们考虑范围顾虑条件。 假设我们的Query的column equivalence class仍然如上面所示，同时我们有$B \lt 10\ and\ C\ \gt 100$，那么有2个column equivalence class有范围过滤条件，我们将这2个class合并得到Query的column列表是$\{A, D, E, C\}$。同时假设MV的范围过滤条件只有$A > 10$，那么MV的范围过滤条件列是$\{A\}$ 。很显然只有Query列集合合并之后的集合是MV的条件过滤列的超集，我们才能从MV中计算出Query。因此我们使用MV的范围条件过滤列构建lattice index，同时并且计算出 Query的扩展范围条件过滤列，从roots开始查找即可。

Stacked MV的匹配

我们将构建在MV之上的MV称作Stacked MV。从理论上将Stacked MV的匹配与原来的base table的匹配没有本质的区别。但是[4]中提到SQL Server中的实现的cascade 优化器有一些问题会导致有些case被忽略。比如我们要匹配$Q = A \bowtie B \bowtie C$，现在有2个MV，其中$V_1 = A \bowtie B$，$V_2 = A \bowtie B \bowtie C$，那么其实Q有2个等价的变换$V_1 \bowtie C$和$V_2$。Cascades优化器会认为这2个变换是一样的，从而只考虑其中的一个。这个在有Stacked MV的情况下可能会有问题，比如我们有$V_3 = V_1 \bowtie C$，$V_4 = \gamma(V_3)$，而$Q^{'} = \gamma(A \bowtie B \bowtie C)$，那么如果如果$Q$的匹配选择的$V_2$，那么就没法$Q^{'}$就没有办法选择到$V_4$，从而没法找到最好的优化。但是去除这个限制盲目的把所有的选项都枚举出来显然会降低效率。

为了解决上面提到的问题，[4]中提出了一个SPJG $Signature$的概念：$S_Q = [G_Q;T_Q;C_Q]$

• $G_Q$用于表示这是SPJ还是SPJG
• $T_Q$是Query中引用到的base table或者MV的集合
• $C_Q$是Query的candidate，对于一个MV来说，当$T_Q \subseteq T_V$是，$V \in C_Q$

SPJG Signature的计算比较简单：

有了计算每个Query的方法，那么计算Memo中Group Expression e的Signature Set的方法就比较简单了：

其中$trees(g)$是以$g$为根节点的等价变换的集合。计算$\varSigma_{g}$的算法如下：

其中$t$表示单独的base table或者MV，$\alpha$表示一元操作符(Selection, projection, group)等，$\beta$表示二院操作符(join)。

而对于 Memo中一个Expression Group g的Signature Set可以用如下方法表示：

在优化器进行exploration的过程中，$\varSigma_{e}, \varSigma^{g}$需要进行动态地维护。

下面我们使用一个例子来演示这个过程，假设$A, B, C, D$是base table，同时我们有如下的几个MV：$V_1 := B \bowtie D, V_2 := A \bowtie B \bowtie C \bowtie D,V_3 := \gamma(C \bowtie V_1)$，如下图所示可以展示变换和维护的过程：

有了SPJG Signature，我们在匹配$B \bowtie C \bowtie D$的过程中可以匹配到$C \bowtie V_1$这个选项，从而最终匹配到$V_3$。

参考文献

1. 查询优化中的物化视图改写（一）:SPJG的改写
2. 查询优化中的物化视图改写（二）:SPOJG的改写
3. Optimizing Queries Using Materialized Views: A Practical, Scalable Solution, 2001
4. Stacked Indexed Views in Microsoft SQL Server, 2005