视图（View）本质上是一个存储在数据库中的命名查询。它不保存数据本身，只保存 SQL 定义。当你查询视图时，数据库会动态执行视图定义的 SELECT 语句，从基表中拉取数据并返回。可以把视图理解为一张“虚拟表”，它的行和列都来源于基础表，但对外表现得就像一张真实的表。
视图常常被轻视，觉得只是保存一段 SQL 而已。但在实际项目中，合理使用视图可以显著简化复杂查询、隔离底层表结构变化、控制数据访问权限。
10.1.1 视图的创建
创建视图使用 CREATE VIEW 语句，基本语法如下：
CREATE VIEW 视图名 [(字段名列表)] AS
SELECT 查询语句
[WITH CHECK OPTION];- 字段名列表是可选的。如果省略，视图的列名与 SELECT 语句输出的列名完全一致。当 SELECT 中使用表达式或函数时，最好显式指定别名，否则视图会继承表达式作为列名，难以阅读。
- SELECT 查询可以是任意合法的查询语句，包括多表连接、子查询、聚合函数、窗口函数等。但 MySQL 对视图定义有一些限制（后面细说）。
WITH CHECK OPTION是一个重要的约束。当视图用于更新（INSERT 或 UPDATE）时，这个选项会强制检查修改后的数据是否仍然满足视图的 WHERE 条件。如果满足，则接受修改；否则拒绝，保证透过视图修改的数据始终是视图可见的。常用于数据安全隔离。
一个典型的例子：假设有一个订单表 orders，包含 id、user_id、amount、status、create_time。我们想为客服人员提供一个只能查看最近 90 天订单的视图，并限制他们只能看到待处理（pending）和已完成（completed）的订单。
CREATE VIEW v_recent_active_orders AS
SELECT id, user_id, amount, status, create_time
FROM orders
WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
AND status IN ('pending', 'completed');创建成功后，你可以像查询真实表一样查询 v_recent_active_orders：
SELECT * FROM v_recent_active_orders WHERE user_id = 101;10.1.2 视图的使用与查询
视图的使用极其简单：在 SQL 中可以出现在任何允许表出现的位置——SELECT、JOIN、子查询，甚至可以基于视图再创建视图。数据库在执行时会先将视图的定义展开，合并到外部查询中，然后统一生成执行计划。
举个例子，对上面的视图进行聚合查询：
SELECT status, COUNT(*) AS cnt, SUM(amount) AS total
FROM v_recent_active_orders
WHERE user_id = 101
GROUP BY status;在 MySQL 内部，这条 SQL 会被合并为类似以下形式（简化表示）：
SELECT status, COUNT(*), SUM(amount)
FROM orders
WHERE create_time >= ...
AND status IN ('pending', 'completed')
AND user_id = 101
GROUP BY status;这里有一个关键认知：视图只是 SQL 片段的代名词，它不会预先计算或缓存结果。如果视图的定义非常复杂（比如多层嵌套、大量聚合），每次查询视图都会实时执行整段逻辑。在频繁访问且数据量巨大的场景中，视图可能带来性能压力。所以它不是性能优化的手段，而是代码组织和安全控制的工具。
另外，MySQL 8.0 支持通用表表达式（CTE），某些原本用视图的场景可以用 CTE 代替。CTE 是临时命名的结果集，只在单条语句内有效，而视图是持久化的数据库对象。如果你的查询仅在一处使用，CTE 更轻量；如果多处复用且有权限控制需求，就使用视图。
10.1.3 视图的更新限制（可更新视图）
你或许会想：“能不能通过视图直接更新基础表的数据？” 答案是可以，但有严格限制。
MySQL 中，只有可更新视图才允许执行 INSERT、UPDATE、DELETE 操作。一个视图要成为可更新视图，必须同时满足以下条件：
- 视图的 SELECT 定义中没有聚合函数（SUM、COUNT、AVG 等）、窗口函数、GROUP BY、HAVING、DISTINCT、UNION 等。
- 视图的 FROM 只能包含一张表（或一个可更新视图），即不能是多表连接视图。
- 视图的 SELECT 不能引用子查询中的列，也不能包含生成列（比如
YEAR(create_time)这种计算字段）。 - 被插入或更新的列必须是基表中直接对应且允许写入的列（不能有只读属性，如通过表达式计算出来的列）。
如果一个视图满足上述条件，它就是可更新的，你可以像操作普通表一样对它增删改。例如，定义一个只暴露部分列的视图：
CREATE VIEW v_user_public AS
SELECT id, nickname, avatar
FROM users;这个视图可直接更新：
UPDATE v_user_public SET nickname = '新昵称' WHERE id = 100;
-- 等价于直接更新 users 表但如果你定义的视图是：
CREATE VIEW v_order_summary AS
SELECT user_id, COUNT(*) AS cnt, SUM(amount) AS total
FROM orders
GROUP BY user_id;这个视图包含聚合和 GROUP BY，它不可更新。执行 INSERT INTO v_order_summary ... 会直接报错。
多表视图的更新限制：即使视图不是聚合视图，但若是连接多个表，MySQL 也只允许对视图进行 INSERT 或 UPDATE 操作，且更新的列必须只涉及其中一张表。具体行为受 sql_safe_updates 等设置影响。实际开发中，极少通过多表视图更新数据，因为语义不清晰，容易误操作。更推荐把视图当成只读查询工具。
WITH CHECK OPTION 的作用：假设你要给某个部门的员工只能修改本部门数据的权限，可以创建一个部门视图，并加上 WITH CHECK OPTION：
CREATE VIEW v_sales_employees AS
SELECT * FROM employees WHERE dept = 'sales'
WITH CHECK OPTION;
UPDATE v_sales_employees SET dept = 'hr' WHERE emp_id = 123;
-- 这条语句会失败！因为修改后的 dept 不再是 'sales'，违反了视图的筛选条件。这能有效防止用户通过视图突破数据边界，实现简单但有效的行级安全。
10.1.4 视图的优点与适用场景
视图在实际项目中的价值主要体现在以下几个方面：
1. 简化复杂查询
当某些复杂的联表、子查询、计算逻辑反复出现时，可以封装成视图，让业务开发人员用一句简单的 SELECT * FROM 视图 WHERE ... 替代几十行的 SQL。例如，电商后台常需要展示带有多级分类名称、品牌名称、价格区间的商品列表，可以创建 v_product_full_info 视图，把这些字段一次性准备好。
2. 逻辑数据隔离与安全控制
视图可以用来对用户隐藏基表的某些列或行。例如，用户表中含有密码、身份证号等敏感字段，可以创建一个不包含这些字段的视图 v_user_safe，然后将应用程序的查询指向该视图，即使 SQL 注入或权限蔓延，也无法直接读取敏感列。再结合 WITH CHECK OPTION，某些用户只能修改自己部门的数据，实现基础的行级权限。
3. 向后兼容与底层表结构演化
当需要对表结构进行拆分或重构时，可以先保留旧表，用新表替换底层实现，同时创建一个与旧表同名的视图，其定义映射到新表，从而让现有应用不受影响。例如，将一张宽表垂直拆分成多张表，可以用视图把它们连接成原来的样子，应用代码无需改动。但要注意，如果视图不支持更新，INSERT/UPDATE/DELETE 就失效了，需要额外处理。
4. 统一指标口径
在企业报表或数据分析中，像“活跃用户”“留存率”这类指标经常有复杂的计算规则。将这些规则定义为视图，各个报表、BI 工具统一查询视图，就能保证口径一致，不会出现“同一个指标不同查询结果”的情况。
视图的不足与注意事项：
- 性能局限：视图本质上只是查询的别名，每次查询都会实时展开并执行，无法预先缓存。如果视图包含多表连接和子查询，且基表巨大，性能会直接取决于底层 SQL 的优化程度。不要指望视图提速，它只负责封装逻辑。
- 优化器处理差异：某些情况下，优化器会将外部条件压入视图内部（谓词下推），但也有失败的情况，尤其是视图定义中含有
LIMIT、GROUP BY时。所以查看执行计划（EXPLAIN）时，要关注合并后的查询。 - 过度嵌套：视图引用视图，再套视图，会让 SQL 极难调试和优化。尽量避免创建多层级的视图链。
- 更新限制：如前所述，只有简单视图才支持数据修改。如果业务中有写操作，视图未必能替代基表。
总结起来，视图是一个轻量、实用的数据库对象。它在读写分离的场景中充当“读模型”，在权限管控中充当“安全窗”，在重构演进中充当“兼容层”。 不必神化它，也不要忽略它。用对地方，它会让你的 SQL 架构更加干净、安全、可维护。