MySQL 5.0以后引入了视图。视图实际是一个自身不存储数据的虚拟数据表。实际这个虚拟表的数据来自于访问视图的 SQL 查询的结果。MySQL 处理视图和处理数据表差不多，通过这种方式来满足很多需求。视图和数据表在 MySQL 中共享命名空间，然而 ，MySQL 处理而二者的方式并不相同，例如，视图没有触发器，并且无法使用 DROP TABLE 移除视图。

下面以 world 样例数据库为例来展示视图的工作机制。

CREATE VIEW Oceania AS
	SELECT * FROM Country WHERE Continent = 'Oceania'
  WITH CHECK OPTION;

实现视图最简单的方式是执行SELECT查询语句并将结果放入到一张临时表中。之后，就可以在视图出现的地方引用这张临时表。例如下面的查询语句：

SELECT Code, Name FROM Oceania WHERE Name = 'Australia';

下面是服务端执行上面语句可能的形式（临时表名称是随意取的，实际内部不知道是什么）：

CREATE TEMPORARY TABLE TMP_Oceania_123 AS 
	SELECT * FROM Country WHERE Continent = 'Oceania';
SELECT Code, Name FROM TMP_Oceania_123 WHERE NAME = 'Australia';

这种形式显然存在性能问题，最好的方式是将视图和查询的分布查询改为一句 SQL 语句，如下所示：

SELECT Code, Name FROM Country
WHERE Continent = 'Oceania' AND Name = 'Australia';

在 MySQL 中会使用两种算法，称之为 MERGE 和 TEMTABLE，而且会尽可能地使用 MERGE 算法。甚至，MySQL 能够将嵌套视图进行合并。下图是两种算法的区别：

当视图中有 GROUP BY，DISTINCT，聚集函数，UNION，子查询或其他数据表之间不是一对一的关系时，MySQL 会使用 TEMPTABLE算法。如果想知道视图是使用 MERGE 还是 TEMPTABLE，可以使用 EXPLAIN 指令检查：

EXPLAIN SELECT * FROM 视图名称>;

如果在 select_type 中有 DERIVED 的话，则表示使用了 TEMPTABLE 算法。因此，如果隐藏的衍生表需要很高的代价产生，EXPLAIN 就会变得性能很低并且执行起来很慢，这是因为它需要实际执行和构建衍生表。这个算法是视图的属性而不会受到查询类型的影响。例如，假设创建视图的时候指定了算法，那么以后针对这个视图的查询都不会更改算法，即便有优化的空间：

CREATE ALGORITHM=TEMPTABLE VIEW v1 AS
SELECT * FROM Country;

可更新视图

可更新视图可以通过视图更新隐藏的基础表，只要指定的条件保持，就可以使用 UPDATE，DELETE 甚至是 INSERT 操作，就像操作普通表一样，例如下面的操作是有效的：

UPDATE Oceania SET Population = Population * 1.1 WHERE NAME = 'Australia';

如果视图包括 GROUP BY，UNION，聚合函数或其他的一些概念，那么该视图就不可更新。所有使用了 TEMPTABLE 算法的视图都不可以更新。

CHECK OPTION 子句用于保证任何通过视图更改的数据行在更改后需要保持与视图的 WHERE条件匹配。例如上面的例子，如果插入了一条 Continent 值不同的行，服务端就会报错。

视图的性能

很多人不会考虑使用视图提升性能，但是在某些情况下视图是可以提高性能的。而且还可以用视图去提升其他方面的性能，例如，在表结构重构时，被修改的数据表的视图不经修改也可以使用。还可以使用视图实现字段权限控制而不增加创建列权限的负荷：

CREATE VIEW public.employeeinfo AS
	SELECT firstname, lastname  --不包含身份证号
  FROM private.employeeinfo;
GRANT SELECT ON public.* to public_user;

使用 TEMPTABLE 算法的视图性能可能很糟糕（虽然也有可能比等效的 SQL 查询性能高）。这种视图可优化的空间不高。

视图可能让开发者误以为视图很简单，而事实上视图非常复杂。如果开发者不懂的试图的复杂性，那么就不会注意到视图与普通表查询之间的差别。如果使用EXPLAIN 指令的话有时候会发现产生上百行的分析结果输出，这是因为实际看起来是数据表的查询实际是视图，而视图可能引用其他数据表甚至是其他视图。

在使用视图改进性能时，需要仔细分析和测试。即便是 MERGE 算法的视图也会增加额外的负担，而且很难预测对性能的影响。视图实际在 MySQL 中使用了另外的优化途径。在高并发场景，视图可能导致查询优化器耗费大量时间在做计划和统计，甚至导致服务端卡顿。这个时候需要使用普通的 SQL 来替代视图。

视图的限制

MySQL 不像其他数据库服务器那样支持物理视图（物理视图即产生并将结果存在一个不可见的数据表中，并周期性地更新以从源数据刷新视图）。MySQL 也不支持视图的索引。MySQL 也不会保留视图的原始 SQL，如果我们视图通过执行 SHOW CREATE VIEW 指令去编辑视图，并且更改返回结果 SQL，会发现结果很奇特。查询SQL会按规范展开，并且使用内部的格式包裹，且没有格式化、注释和缩进。

以上就是MySQL 视图（View）原理解析的详细内容，更多关于MySQL 视图（View）原理的资料请关注脚本之家其它相关文章！