mysql中的视图是基于一条或多条SQL查询语句的结果集构建的虚拟表，它本身不存储实际数据，数据来源于关联的基表。视图在数据库开发中有着明确的适用场景，合理使用的价值很高。
视图的核心作用
简化复杂查询逻辑
当业务中存在频繁使用的多表关联、复杂条件过滤的查询时，可以将这些查询逻辑封装成视图，后续只需要查询视图即可，不需要重复编写复杂的SQL语句。
比如需要频繁查询用户的基本信息和最近一次订单的时间，原始查询语句如下：
SELECT
u.id,
u.username,
u.email,
MAX(o.create_time) AS last_order_time
FROM user u
LEFT JOIN order o ON u.id = o.user_id
GROUP BY u.id, u.username, u.email;
可以将上述逻辑封装为视图：
CREATE VIEW user_last_order_view AS
SELECT
u.id,
u.username,
u.email,
MAX(o.create_time) AS last_order_time
FROM user u
LEFT JOIN order o ON u.id = o.user_id
GROUP BY u.id, u.username, u.email;
后续查询只需要执行：
SELECT * FROM user_last_order_view WHERE id = 1;
实现细粒度的权限控制
mysql的权限控制可以精确到表级别，但如果需要限制用户只能访问表中的部分字段或部分行数据，直接授权表无法满足需求，此时可以通过视图实现。
比如用户表user包含密码字段password，不希望给业务开发人员开放该字段的访问权限，可以创建不包含密码字段的视图：
CREATE VIEW user_public_view AS SELECT id, username, email, phone FROM user;
然后给开发人员授予user_public_view的查询权限，即可避免密码字段泄露。
封装数据逻辑，降低耦合
当基表的结构发生变更时，如果业务直接依赖基表查询，需要修改所有相关的SQL语句。如果通过视图封装查询逻辑，只需要修改视图的定义，上层业务的查询语句不需要变动。
比如原来的订单表order拆分为order_base和order_ext两张表，原来的查询视图可以修改为关联两张新表，上层业务查询视图的语句不需要任何调整。
视图的使用限制
视图虽然用处很多，但也存在明显的限制，不适合所有场景：
- 视图是虚拟表，查询视图时本质上还是会执行视图对应的基表查询，如果基表查询本身性能很差，视图查询的性能也不会提升，甚至会因为额外的视图解析开销略有下降。
- mysql中部分视图不支持更新操作，比如包含聚合函数、GROUP BY、DISTINCT等逻辑的视图，只能用于查询，不能执行INSERT、UPDATE、DELETE操作。
- 视图的嵌套层级不宜过多，多层嵌套的视图会导致查询逻辑难以排查，同时也会增加查询优化器的解析成本。
适用场景判断
如果你的业务中存在以下情况，使用视图的收益会比较高：
- 存在大量重复的复杂查询逻辑，需要减少代码冗余。
- 需要对不同角色的用户开放不同范围的数据访问权限。
- 基表结构可能变更，希望上层业务查询逻辑保持稳定。
如果只是简单的单表查询，或者查询逻辑很少重复使用，那么视图带来的收益有限，不需要刻意创建视图。
视图的基本操作示例
创建视图的语法如下：
CREATE [OR REPLACE] VIEW 视图名 [(列名列表)] AS 查询语句;
查询视图和查询普通表的语法一致：
SELECT 列名 FROM 视图名 WHERE 条件;
查看已有视图的定义：
SHOW CREATE VIEW 视图名;
删除视图的语法：
DROP VIEW [IF EXISTS] 视图名;