视图是保存的SELECT查询，不存储数据而只保存逻辑。它简化重复查询、控制数据可见性、屏蔽底层表结构变更，但创建时需注意语法限制、延迟校验及更新条件。
视图就是“保存下来的 SELECT 查询”，不存数据，只存逻辑
MySQL 中的视图（VIEW）不是一张真实表，而是一条被命名、存进数据库的 SELECT 语句。每次你 SELECT * FROM my_view，MySQL 都会实时去执行它背后定义的查询，从基表里拉数据——所以视图里的数据永远和基表保持同步，删了基表数据，视图查出来就少；改了基表字段名，视图可能直接报错。
为什么非得用视图？三个最实在的场景
视图不是炫技，是解决具体问题的工具：
-
简化重复查询：比如销售部门员工名单要查 10 次，每次都写
SELECT id,name,salary FROM employees WHERE dept = 'Sales'？不如建个sales_employees视图，以后一句SELECT * FROM sales_employees就完事。 -
控制数据可见性：HR 系统里，普通员工只能看自己的姓名、部门、入职时间，但不能看工资和身份证号。建视图时只选这几列，再把表权限收回、只给视图
SELECT权，就自然隔离了敏感字段。 -
屏蔽底层变更：原
users表拆成了users_basic和users_profile，只要把视图定义改成JOIN两张新表，所有依赖该视图的应用代码完全不用改。
创建视图的语法和几个关键注意点
基本写法很简单：CREATE VIEW view_name AS SELECT ...，但容易踩坑的地方不少：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须有
SELECT，不能带ORDER BY（除非配合LIMIT），否则会报错ERROR 1351: View's SELECT contains a variable or parameter类似提示。 - 如果基表不存在，或字段名写错，
CREATE VIEW会成功，但第一次SELECT时才报错——这是 MySQL 的“延迟校验”机制，务必在建完后立刻试查一次。 - 多表关联时，列名要唯一。比如
SELECT a.id, b.id FROM t1 a JOIN t2 b会失败，得写成SELECT a.id AS aid, b.id AS bid，否则视图无法创建。 - 想让视图支持更新（
UPDATE/INSERT），必须满足严格条件：不能含聚合函数、DISTINCT、子查询、UNION，且必须能明确映射回单个基表的某一行。
怎么确认视图到底长啥样？别只信文档
开发中常遇到“这个视图谁写的？查的是哪几张表？”——靠记忆或文档不可靠，直接查数据库：
- 看定义：
SHOW CREATE VIEW sales_employees，返回完整的建视图语句，一目了然。 - 看元数据：
SELECT TABLE_NAME, VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'your_db'，适合批量检查所有视图。 - 千万别用
DESCRIBE view_name查结构——它只显示列名和类型，不告诉你来源；真正关键的逻辑藏在定义里。
视图本身轻量，但它的威力取决于你怎么定义那条 SELECT。写得太复杂（比如嵌套 5 层子查询）会导致每次查都变慢；写得太松（没加 WHERE 过滤）可能暴露不该看的数据——它不自动做安全兜底，逻辑全在你那一行 SQL 里。
