ToprowDB Dynamic Server 查询优化技术--02--视图优化

ToprowDB Dynamic Server 查询优化技术
华胜信泰架构师  李海翔

（二）ToprowDB Dynamic Server 查询优化技术之视图
本篇是《ToprowDB Dynamic Server 查询优化技术》系列的第二篇，探讨ToprowDB逻辑查询优化技术中的视图优化技术。
视图优化是一个热门技术，在SQL优化技术中，视图优化非常重要。不恰当地使用视图，会造成严重的性能问题，这使得SQL开发者不得不特别重视视图优化的技术。
1 一些误区
当前，一数SQL开发者对视图的概念、视图的优化技术的理解存在偏差，所以在介绍视图优化技术前，我们将简单溯源，聊一个常规式的问题：什么是视图？在探索这个问题前，我们先看看一些常见对视图认识上的误区。
 

     比如说上图源自网上的公开资料，说使用视图“查询性能提高”。这就是一个误区。
    还有的童鞋们认为（如下图），“视图嵌套不要过深,一般视图嵌套不要超过2个为宜”，至于视图为什么嵌套不要过深还是可以有很多嵌套层次，却不明就里。那么，使用ToprowDB，是不是也存在这样的问题呢？
 

     再比如，百度百科对Oracle的视图分为5类，这5类分法是从不同角度出发的，这个分类角度显得十分混乱。这表明对于视图缺乏正确的认识和理解。
 

 

     上面这3类问题，能够表明，我们对于视图的概念是不清晰的，对于视图的用途是不清楚的，对于视图优化技术是不了解的。
    带着这些问题，我们来关注“Informix技术中国”微信号，一起探索答案。^_^

2 什么是视图？
ToprowDB和大家一起追溯一下源头,来看看SQL标准是怎么定义视图的。
 

     SQL标准首先认为视图是一个query，即一个查询，这点可以从定义视图的SQL语句中看出来，视图的主体是一个SELECT语句。
    其次，视图是一个“named”即有名字的query，这点区别于普通的一条SQL语句，因为有名字存在，别人就可以去喊这个名字去写这个名字，所以就可以在一条SQL语句中去操作视图。如在DML语句中修改视图中的数据（可被这么操作，被称为“可更新视图”），在DQL语句中查询数据（视图位于SELECT语句内部，就存在了嵌套层次——查询中存在其他查询块，因嵌套为SQL带来了复杂性。因嵌套+query，还可以想到什么呢？）。
    再次，视图可以象基表（base table，即通过CREATE TABLE语句创建的表）一样被用户使用，这是在告诉我们，视图的地位相当于表（由此可以理解在PostgreSQL中，为什么视图和表的定义即元数据被同等地存放在了系统表pg_class中）。

3 视图优化技术
    这一节，我们直接步入正题，来探索一下视图优化技术。
首先，视图是核心，但因SQL语句对视图使用、存在性能问题。
其次，视图优化，特别指的是“优化器对于视图的优化技术”。这里要对视图进行分类（注意分类的角度和百度百科不一样哦），根据是否能进行优化来对视图分类。
再次，用户在使用视图的过程中遇到使用视图时存在性能问题，需要对“视图进行优化”，这种情况会存在，但是应该是在视图被优化器优化之后发生的工作，这时，要想优化视图，就需要注意掌握“优化器对于视图的优化技术”中提到的优化规则，进而利用好这些规则才能进一步改写、优化SQL。
接下来，我们用具体示例，来说明视图优化的技术。
 

 
3.1 数据准备
准备工作：

1 创建2张表
CREATE TABLE t1 (id1 INT, a1 INT UNIQUE, b1 INT, PRIMARY KEY(id1));
CREATE TABLE t2 (id2 INT, a2 INT UNIQUE, b2 INT, PRIMARY KEY(id2));
CREATE TABLE t3 (id3 INT, a3 INT UNIQUE, b3 INT, PRIMARY KEY(id3));

2 创建一个简单视图、一个复杂视图、一个使用UNOION操作的视图
CREATE VIEW v_SPJ  AS  SELECT * FROM t1, t2;
CREATE VIEW v_NON_SPJ  AS
    SELECT DISTINCT t1.b1, t2.b2 FROM t1, t2 GROUP BY t1.b1, t2.b2;
CREATE VIEW v_UNION (id11,a11,b11)  AS  SELECT * FROM t1 UNION SELECT * FROM t2;
CREATE VIEW v_SPJ_1  AS  SELECT * FROM t1, t2 WHERE id1=id2;

3 插入少量数据
INSERT INTO t1 VALUES (1,1,1);  …(2,2,2); …(3,3,3);
INSERT INTO t2 VALUES (1,1,1); …(2,2,2); …(30,30,30);
INSERT INTO t3 VALUES (1,1,1); …(2,2,2); …(3,3,3); …(4,4,1); …(5,5,2); …(6,6,3);

3.2 SPJ类型视图
SPJ类型的视图，是可以被优化的。
什么是SPJ呢？S，SELECT；P，Project；J，Join。很简单吧，就是SQL语句中存在这三种操作，没有其他操作，这样的query被称为SPJ查询。
什么是SPJ类型的视图呢？即用SPJ查询定义的视图，就是SPJ类型的视图。

    我们用例子来说明，但请注意下面的INSERT只适用于本用例（除数据准备插入数据外，再额外插入如下数据）：
INSERT INTO t2  VALUES  (7,7,1);  …(8,8,2) ; …(9,9,3) ; …(4,4,1) ; …(5,5,2) ; …(6,6,3);
    然后在表上执行统计信息更新。（这一步很重要的 ，不然，可能得不到正确的执行计划）。

接下来，我们执行带有视图的一个查询，如下：
SELECT * FROM v_SPJ, t3;

然后得到查询执行计划如下：
 

     首先，看右侧的“Table map”，“table name”表示原始SQL中的表名称，“Internal name”表示在执行计划里显示的表名称（有点小混乱吧？^_^,以后写表名的时候，不要定义为t1、t2这样的就好了，不过在上面的执行计划里这么做，有一点点好处，就是执行计划能对齐显示）。
其次，看左侧的执行计划，t1和t2首先连接，得到的结果然后才与t3连接。这表明原始SQL中的t1和t3先连接，然后才与t2连接。而v_SPJ这个视图的定义中，可是原始的t1和t2之间进行连接，现在这个连接方式不存在了，即视图被“拆分”了（打破旧世界，建立新世界，视图解体了）。
视图被“拆分”，其实是优化器对于视图的优化的结果。但请注意，这里的视图，是SPJ类型的视图，为什么特别强调SPJ类型呢，因为，存在一个非SPJ类型的视图。

3.3 非SPJ类型的视图
    非SPJ视图，如果视图的定义中包含有如下子句：
1 GROUP BY子句
2 DISTNICT子句
3 聚集函数
4 带有集合操作: UNION / UNION DISTINCT / UNION ALL
5 带有分析函数、connect by、OUTER JOIN、PL/SQL function等

因语义的限制，非SPJ视图不可被分解，即不可以被优化（即使是非常简单的视图，多数数据库也没有对非SPJ视图进行优化）。
我们用一个例子来说明：
执行：SELECT * FROM t3, v_NON_SPJ;
 

 左侧执行计划中的t1和t2，是原始SQL中的t2和t1，这2个表作了连接操作，得到一个临时的结果集（(Temp Table For View)），这说明视图v_NON_SPJ没有解体，即视图v_NON_SPJ的query被单独执行了。换句话说，v_NON_SPJ视图，非SPJ类型的视图不能被优化。

3.4 嵌套层次与视图优化的关系
    在第一节，我们提到一些误区，其中，有个观点是“视图嵌套不要过深,一般视图嵌套不要超过2个为宜”，但是，如果视图是SPJ类型的视图，视图的优化和嵌套层次是没有关系的。
 

     从图里我们可以看出，视图解体，嵌套层次消失，5层的嵌套被消减为2层且嵌套消失。

4 ToprowDB的视图优化技术
前面我们探讨了优化器对视图的常规的优化规则，知道了SPJ类型的视图是可以被优化的。
那么，ToprowDB数据库，是否支持视图优化呢？
从第3节，我们完全可以猜测，所举的事例，其实都是ToprowDB数据库的例子，所以可以看出，ToprowDB数据库是完全支持视图优化的。

5 主流数据库视图优化技术对比
    一表胜千言，继续用表格直接给出对比。