【MYSQL】MYSQL学习的一大重点：视图

🎬 个人主页 ：艾莉丝努力练剑
❄专栏传送门 ：《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》
《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

🎬 艾莉丝的简介：

文章目录

[0 ~> 前置概念辨析](#0 ~> 前置概念辨析)
- [0.1 两个 "视图" 的本质区分](#0.1 两个 “视图” 的本质区分)
[1 ~> 视图基础概念](#1 ~> 视图基础概念)
- [1.1 核心定义](#1.1 核心定义)
- - [1.1.1 易错问题](#1.1.1 易错问题)
- [1.2 基表与视图的联动关系](#1.2 基表与视图的联动关系)
- - [1.2.1 纠正](#1.2.1 纠正)
[2 ~> 视图基本操作](#2 ~> 视图基本操作)
- [2.1 创建视图](#2.1 创建视图)
- - [2.1.1 标准语法](#2.1.1 标准语法)
  - [2.1.2 示例](#2.1.2 示例)
- [2.2 查询视图](#2.2 查询视图)
- [2.3 视图数据修改](#2.3 视图数据修改)
- - [2.3.1 通过视图修改基表](#2.3.1 通过视图修改基表)
  - [2.3.2 修改基表同步到视图](#2.3.2 修改基表同步到视图)
  - [2.3.3 可更新视图的核心约束](#2.3.3 可更新视图的核心约束)
- [2.4 删除视图](#2.4 删除视图)
- - [2.4.1 标准语法](#2.4.1 标准语法)
  - [2.4.2 示例](#2.4.2 示例)
[3 ~> 视图规则与使用限制](#3 ~> 视图规则与使用限制)
[4 ~> 工程实践与行业现状](#4 ~> 工程实践与行业现状)
- [4.1 视图的核心价值](#4.1 视图的核心价值)
- [4.2 大厂使用规范](#4.2 大厂使用规范)
[5 ~> 实战例题](#5 ~> 实战例题)
- [5.1 题目](#5.1 题目)
- [5.2 标准解答](#5.2 标准解答)
结尾

0 ~> 前置概念辨析

0.1 两个 "视图" 的本质区分

明确强调二者无任何关联，更加精准的定义如下：

本文的视图（View）：数据库模式层面的对象，是一段被命名存储的 SELECT 查询定义，以虚拟表的形式对外提供访问能力，属于 SQL 标准语法范畴。
事务中的 Read View：InnoDB 引擎 MVCC 机制的底层组件，是事务执行快照读时生成的可见性判断快照，用于判定当前事务能看到哪些版本的行数据，属于事务隔离级别的内部实现逻辑。

二者分属完全不同的技术维度，没有任何关联。

1 ~> 视图基础概念

1.1 核心定义

视图是一个虚拟表，其内容由查询定义，同真实表一样包含命名的列和行数据。

1.1.1 易错问题

如下所示：

"在内存级别上创建好了一张表""把筛选出来的数据插入到表中""查询结果变成了一个临时表结构"
1. 视图本身不存储任何数据 ，也不会默认生成内存临时表。视图的本质是一段被持久化存储的 SELECT 查询语句。当查询视图时，MySQL 会将视图定义与外层查询合并后执行，所有数据均实时从基表计算得到。
2. 补充执行算法：
  - MERGE 合并算法（默认优先）：将视图定义的 SQL 与外层查询 SQL 合并为单条语句执行，无额外临时表开销，性能等价于直接执行原生查询。
  - TEMPTABLE 临时表算法：当视图定义包含聚合、分组、DISTINCT 等无法合并的逻辑时，MySQL 先将视图查询结果写入临时表（内存或磁盘），再基于临时表执行外层查询，存在额外性能开销。
"视图本质上就是一种表结构 "
1. 视图是虚拟表，仅存储定义元数据（MySQL 5.x 存 .frm 结构文件，8.0 后纳入数据字典），没有对应的 .ibd 数据文件，不持久化存储行数据，与物理基表有本质区别。删除视图后无对应数据文件，也印证了这一点。

1.2 基表与视图的联动关系

这个表述对吗：视图的数据变化会影响基表，基表的数据变化也会影响视图。

1.2.1 纠正

实际上该结论存在前提缺失，完整严谨的表述为：

基表变更 → 视图同步变更：恒成立。视图数据是查询时实时计算生成，基表数据变更后，再次查询视图必然反映最新数据。
视图变更 → 基表同步变更 ：仅可更新视图支持，且存在严格的语法约束。绝大多数复杂视图（聚合、多表深度连接等）无法执行写入操作。

2 ~> 视图基本操作

2.1 创建视图

2.1.1 标准语法

create view视图名as select语句;存在空格缺失问题，标准语法如下：

sql 复制代码

CREATE [OR REPLACE] VIEW 视图名 [(自定义列名列表)]
AS SELECT 查询语句
[WITH [CASCADED | LOCAL] CHECK OPTION];

关键字说明：

OR REPLACE：视图已存在时直接覆盖原有定义，避免重名报错。
自定义列名列表：可重命名视图的输出列，数量必须与 SELECT 结果列数一致；不指定则默认沿用 SELECT 的列名。
WITH CHECK OPTION：写入视图数据时校验数据是否满足视图的 WHERE 过滤条件，防止写入后数据从视图中 "消失"。

2.1.2 示例

基于 EMP、DEPT 表创建员工姓名 - 部门名称视图。

sql 复制代码

-- 创建内连接视图
CREATE VIEW v_ename_dname AS
SELECT emp.ename, dept.dname
FROM emp
INNER JOIN dept ON emp.deptno = dept.deptno;

2.2 查询视图

视图的查询语法与普通物理表完全一致，支持 WHERE、ORDER BY、联表等所有查询语法。

sql 复制代码

-- 查询视图并按部门排序
SELECT * FROM v_ename_dname ORDER BY dname;

执行逻辑等价于直接运行视图定义的完整 SELECT 语句。

2.3 视图数据修改

2.3.1 通过视图修改基表

示例：更新视图中的员工姓名，基表同步变更。

sql 复制代码

-- 通过视图更新员工姓名
UPDATE v_ename_dname SET ename = 'smith' WHERE ename = 'SMITH';

执行结果：视图与基表 emp 的 ename 字段同步更新。
成立前提：ename 列唯一来自单表 emp，且视图满足可更新条件；若尝试更新 dname（来自 dept 表），多表连接视图通常不支持跨表更新。

2.3.2 修改基表同步到视图

示例：更新基表部门名称，视图数据同步变更。

sql 复制代码

-- 修改基表 DEPT 的部门名称
UPDATE dept SET dname = 'aaaaa' WHERE deptno = 30;

执行结果：再次查询视图，所有 30 号部门对应的 dname 同步更新。
结论：基表数据变更必然实时反映到视图中，无任何前提条件。

2.3.3 可更新视图的核心约束

补充工业界标准约束。

视图支持 UPDATE/INSERT/DELETE 必须同时满足：

无聚合函数（SUM/COUNT/MAX 等）、无 GROUP BY、无 DISTINCT、无 UNION、无 HAVING。
视图列不能是表达式、常量或函数计算的结果。
单表视图天然支持更新；多表连接视图仅允许更新其中一张基表的列，且连接不能导致行映射歧义。
FROM 子句中不能包含子查询。

2.4 删除视图

2.4.1 标准语法

sql 复制代码

DROP VIEW [IF EXISTS] 视图名;

2.4.2 示例

sql 复制代码

DROP VIEW v_ename_dname;

执行后仅删除视图的定义元数据，不会对基表数据产生任何影响。
物理层面：删除视图不会删除任何 .ibd 数据文件，仅移除对应的视图定义文件。

3 ~> 视图规则与使用限制

命名唯一性：同一数据库内，视图名不能与表名、其他视图名重复。
创建数量无上限：但复杂查询定义的视图会增加优化器解析成本，可能导致执行计划退化，不建议滥用。
功能限制 ：普通视图无法创建索引，无法关联触发器，不能为列设置默认值。
1. 注：MySQL 原生不支持物化视图，无法为视图持久化存储数据与索引；若需物化视图需通过定时任务生成物理表手动模拟。
权限规则：访问视图需要拥有视图的对应权限，同时视图创建者必须拥有基表的查询权限。视图可实现列级权限控制，只向用户开放允许查看的字段。
排序覆盖规则：视图定义中可以写 ORDER BY，但如果查询视图的外层语句也包含 ORDER BY，视图内部的排序会被外层覆盖，最终以外层排序为准。
联表兼容性：视图可与普通物理表混合使用，支持内连接、外连接、子查询等所有表级查询语法。

4 ~> 工程实践与行业现状

4.1 视图的核心价值

判断一下，下面这句话的表述有没有问题："高频访问不用做多表查询、字段更清晰"。

这句话是有问题的，下面纠正一下：

SQL 复用与简化：将复杂多表关联封装为视图，业务层直接调用，避免重复编写冗余 SQL，降低维护成本。
逻辑解耦：基表结构变更时，可通过修改视图定义屏蔽底层变化，上层业务代码无需改造。
数据安全：实现行列级权限隔离，例如只开放员工姓名、部门字段，隐藏薪资、身份证等敏感数据。
性能误区修正 ：视图不会提升查询性能。MERGE 算法下性能与原生 SQL 完全等价；TEMPTABLE 算法下反而会增加临时表开销，性能下降。原始笔记中 "方便快速读取" 指的是编写便捷，而非执行性能提升。

4.2 大厂使用规范

互联网行业普遍现状，大厂内部限制使用视图，核心原因如下：

运维成本高：业务逻辑下沉到数据库层，增加了 SQL 排查、优化的复杂度，不利于 DBA 统一管控。
架构扩展性差：分库分表、读写分离的分布式架构下，视图基本无法正常使用。
研发规范约束：主流研发规范要求业务逻辑全部收敛在应用代码层，数据库仅负责数据存储，避免数据库逻辑过重导致整体架构僵化。
学习建议：视图是 SQL 标准核心概念，必须掌握其原理与语法；生产环境需谨慎评估，优先在业务代码层封装查询逻辑。

5 ~> 实战例题

5.1 题目

针对 actor 表创建视图 actor_name_view，只包含 first_name 以及 last_name 两列。

5.2 标准解答

sql 复制代码

CREATE VIEW actor_name_view AS
SELECT first_name, last_name
FROM actor;

结尾

uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ### 艾莉丝努力练剑 C/C++ & Linux 底层探索者 | 一个正在努力练剑的技术博主 *** ** * ** *** 👀 【关注】 跟随我一起深耕技术领域，见证每一次成长。 ❤️ 【点赞】 让优质内容被更多人看见，让知识传递更有力量。 ⭐ 【收藏】 把核心知识点存好，在需要时随时查、随时用。 💬 【评论】 分享你的经验或疑问，评论区一起交流避坑！ 不要忘记给博主"一键四连"哦！ "今日练剑达成！" "技术之路难免有困惑，但同行的人会让前进更有方向。" |

结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主"一键四连"哦！

往期回顾：

【MYSQL】MYSQL学习的一大重点：事务（下）- InnoDB 事务隔离性原理（MVCC 视角）

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡 ૮₍ ˶ ˊ ᴥ ˋ˶₎ა