MySQL 视图（View）原理解析

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

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

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';

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

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

EXPLAIN SELECT * FROM <视图名称>;

CREATE ALGORITHM=TEMPTABLE VIEW v1 ASSELECT * FROM Country;

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

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

视图的性能

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

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

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

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

视图的限制

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

视图的性能

视图的限制

更多相关文章

随机推荐