参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/views.html

MySQL支持视图，包括可更新视图。 视图是存储的查询，在调用时会生成结果集。 视图充当虚拟表。

以下讨论描述了创建和删除视图的语法，并显示了如何使用它们的一些例子。

23.5.1 视图语法

CREATE VIEW语句创建一个新视图。 要更改视图的定义或删除视图，请使用ALTER VIEW 或DROP VIEW

可以从多种SELECT语句创建视图。 它可以引用基表或其他视图。 它可以使用连接，UNION和子查询。 SELECT甚至不需要引用任何表。 以下示例定义了一个视图，该视图从另一个表中选择两列，以及从这些列计算的表达式：

mysql> CREATE TABLE t (qty INT, price INT);

mysql> INSERT INTO t VALUES(3, 50), (5, 60);

mysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;

mysql> SELECT * FROM v;

23.5.2 视图处理算法

CREATE VIEW或ALTER VIEW的可选ALGORITHM子句是标准SQL的MySQL扩展。 它会影响MySQL处理视图的方式。 ALGORITHM有三个值：MERGE，TEMPTABLE或UNDEFINED。

• 对于MERGE，将合并引用视图和视图定义的语句的文本，以便视图定义的某些部分替换语句的相应部分。

--视图语句替换执行语句

• 对于TEMPTABLE，视图的结果将被检索到临时表中，然后用于执行该语句。
• 对于UNDEFINED，MySQL选择使用哪种算法。 如果可能的话，它更喜欢MERGE而不是TEMPTABLE，因为MERGE通常更有效，并且如果使用临时表，则视图无法被更新。
• 如果不存在ALGORITHM子句，则UNDEFINED是MySQL 5.7.6之前的默认算法。 从5.7.6开始，默认算法由optimizer_switch系统变量的derived_merge标志的值确定。

明确指定TEMPTABLE的一个原因是，在创建临时表之后以及在用于完成处理语句之前，可以在基础表上释放锁。 这可能导致比MERGE算法更快的锁定释放，因此使用该视图的其他客户端不会被阻止。

视图算法可以是 UNDEFINED 的，原因有三个：

• CREATE VIEW语句中不存在ALGORITHM子句。
• CREATE VIEW语句具有显式的ALGORITHM = UNDEFINED子句。
• ALGORITHM = MERGE是为只能使用临时表处理的视图指定的。 在这种情况下，MySQL会生成警告并将算法设置为UNDEFINED。

如前所述，MERGE是通过将视图定义的相应部分合并到引用视图的语句中来处理的。 以下示例简要说明了MERGE算法的工作原理。 这些示例假设有一个具有此定义的视图v_merge：

CREATE ALGORITHM = MERGE VIEW

v_merge (vc1, vc2)

AS SELECT c1, c2 FROM t WHERE c3 > 100;

例子1：假设我们发出以下语句：

SELECT * FROM v_merge;

MySQL处理语句如下：

• v_merge变成t
• *变为vc1，vc2，对应于c1，c2
• 添加视图WHERE子句

生成的语句将变为：

SELECT c1, c2 FROM t WHERE c3 > 100;

例子2：假设我们发出以下语句：

SELECT * FROM v_merge WHERE vc1 < 100;

此语句的处理方式与前一个语句类似，不同之处在于vc1 <100变为c1 <100，并且使用AND连接将视图WHERE子句添加到语句WHERE子句中（并添加括号以确保子句的各部分已执行 正确的优先权）。 生成的语句将变为：

SELECT c1, c2 FROM t WHERE (c3 > 100) AND (c1 < 100);

实际上，要执行的语句具有此形式的WHERE子句：

WHERE (select WHERE) AND (view WHERE)

如果不能使用MERGE算法，则必须使用临时表。合并阻止的结构和单个表的结构相同。 例如是子查询中的SELECT DISTINCT或LIMIT。

23.5.3 可更新的和可插入视图

某些视图是可更新的，对它们的引用可用于在数据更改语句中，更新指定的表。 也就是说，您可以在UPDATE，DELETE或INSERT等语句中使用它们来更新基础表的内容。 派生表也可以在多表UPDATE和DELETE语句中指定，但只能用于读取数据以指定要更新或删除的行。 通常，视图引用必须是可更新的，这意味着它们可以合并而不是被物化的。 复合视图具有更复杂的规则。

要使视图可更新，视图中的行与基础表中的行之间必须存在一对一的关系。 还有一些其他构造使视图不可更新。 更具体地说，如果视图包含以下任何内容，则视图不可更新：

• 聚合函数（SUM（），MIN（），MAX（），COUNT（）等）
• DISTINCT
• GROUP BY
• HAVING
• UNION或UNION ALL
• 选择列表中的子查询

在MySQL 5.7.11之前，查询列表中的子查询对INSERT失败，但对于UPDATE，DELETE是可以的。 从MySQL 5.7.11开始，对于非依赖子查询仍然如此。 对于select列表中的依赖子查询，不允许使用数据更改语句。

• 某些连接（请参阅本节后面的其他连接讨论）
• FROM子句中引用nonupdatable视图
• WHERE子句中的子查询，它引用FROM子句中的表
• 仅关联文字值（在这种情况下，没有要更新的基础表）
• ALGORITHM = TEMPTABLE（使用临时表总是使视图不可更新）
• 对基表的任何列的多次引用（对于INSERT失败，对于UPDATE，DELETE是可以的）

视图中生成的列被视为可更新，因为可以为其分配。 但是，如果明确更新此列，则唯一允许的值为DEFAULT。

假设可以使用MERGE算法处理多表视图，则有时可以更新多表视图。 为此，视图必须使用内部联接（非外联接或UNION）。 此外，只能更新视图定义中的单个表，因此SET子句必须只列出视图中其中一个表的列。 即使它们在理论上可以更新，也不允许使用UNION ALL的视图。

关于可插入性（可使用INSERT语句更新），如果可更新视图也满足视图列的这些附加要求，则可插入视图：

• 必须没有重复的视图列名称。
• 视图必须包含基表中没有默认值的所有列。
• 视图列必须是简单的列引用。 它们不能是表达式，例如：

3.14159 col1 + 3 UPPER(col2) col3 / col4 (subquery)

MySQL在CREATE VIEW时设置一个标志，称为视图可更新性标志。 如果UPDATE和DELETE（以及类似操作）对于视图是合法的，则该标志设置为YES（true）。 否则，该标志设置为NO（false）。 INFORMATION_SCHEMA.VIEWS表中的IS_UPDATABLE列显示此标志的状态。

如果视图不可更新，则UPDATE，DELETE和INSERT等语句是非法的并被拒绝。 （即使视图是可更新的，也可能无法插入）

如果视图依赖于一个或多个其他视图，并且更新其中一个基础视图，则IS_UPDATABLE标志可能不可靠。 无论IS_UPDATABLE值如何，服务器都会跟踪视图的可更新性，并正确拒绝对不可更新的视图的数据更改操作。 如果视图的IS_UPDATABLE值由于对基础视图的更改而变得不准确，则可以通过删除并重新创建视图来更新该值。

视图的可更新性可能受updatable_views_with_limit系统变量的值的影响。

23.5.4 视图的 WITH CHECK OPTION 子句

可以为可更新视图指定WITH CHECK OPTION子句，以防止插入到select_statement中WHERE子句不为true的行。 它还会阻止那些更新WHERE子句为true，但更新会导致其不为true的行（换句话说，它会阻止将可见行更新为不可见的行）。

在可更新视图的WITH CHECK OPTION子句中，LOCAL和CASCADED关键字在根据另一个视图定义视图时确定检查测试的范围。 如果没有给出关键字，则默认为CASCADED。

在MySQL 5.7.6之前，WITH CHECK OPTION测试的工作原理如下：

• 使用LOCAL，将检查视图WHERE子句，但不检查基础视图。
• 使用CASCADED，检查视图WHERE子句，然后检查递归到基础视图，并向它们添加WITH CASCADED CHECK OPTION（为了检查;它们的定义保持不变），并应用相同的规则。
• 如果没有检查选项，则不会检查视图WHERE子句，也不会检查基础视图。

从MySQL 5.7.6开始，WITH CHECK OPTION测试符合标准（从以前的LOCAL和no check子句改变了语义）：

• 使用LOCAL，将检查视图WHERE子句，然后检查递归到基础视图并应用相同的规则。
• 使用CASCADED，检查视图WHERE子句，然后检查递归到基础视图，并向它们添加WITH CASCADED CHECK OPTION（为了检查;它们的定义保持不变），并应用相同的规则。
• 如果没有check选项，则不检查视图WHERE子句，然后检查递归到基础视图，并应用相同的规则。

考虑下表和视图集的定义：

CREATE TABLE t1 (a INT);

CREATE VIEW v1 AS SELECT * FROM t1 WHERE a < 2

WITH CHECK OPTION;

CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0

WITH LOCAL CHECK OPTION;

CREATE VIEW v3 AS SELECT * FROM v1 WHERE a > 0

WITH CASCADED CHECK OPTION;

这里v2和v3视图是根据另一个视图v1定义的。 在MySQL 5.7.6之前，由于v2具有LOCAL检查选项，因此仅针对v2检查测试插入。 v3具有CASCADED检查选项，因此插入不仅针对v3检查进行测试，还针对基础视图进行测试。 以下语句说明了这些差异：

mysql> INSERT INTO v2 VALUES (2);

Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO v3 VALUES (2);

ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'

从MySQL 5.7.6开始，LOCAL的语义与以前不同：根据其LOCAL检查选项检查v2的插入，然后（与5.7.6之前不同），检查将递归到v1并再次应用规则。 v1的规则导致检查失败。 对v3的检查与以前一样失败：

mysql> INSERT INTO v2 VALUES (2); ERROR 1369 (HY000): CHECK OPTION failed 'test.v2'

mysql> INSERT INTO v3 VALUES (2); ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'

23.5.5 视图元数据

• 查询INFORMATION_SCHEMA数据库的VIEWS表。
• 使用SHOW CREATE VIEW语句。