必须用create view创建视图，不能用select临时替代；视图是固化查询逻辑的虚拟表，需显式命名、避免子查询和变量，多表join须加表别名并慎用inner join，优先left join+coalesce处理空值，单表视图建议加with check option保障一致性，修改视图需显式重写该选项，且须提前检查基表结构依赖。
创建视图时必须用 CREATE VIEW，不能用 SELECT 临时替代
很多人第一次想“存下复杂查询”，直接复制一段 SELECT ... JOIN ... GROUP BY 去执行，发现只是查了一次数据，下次还得重写。视图不是结果缓存，而是把查询逻辑固化到数据库里——只有用 CREATE VIEW 才算真正注册了一个可复用的虚拟表。
常见错误现象：执行完 SELECT 就以为“保存成功”，后续 SELECT * FROM my_view 报错 Table 'db.my_view' doesn't exist。
-
CREATE VIEW必须带明确的视图名，且命名要符合标识符规则（不能含空格、特殊符号） - 定义语句中不能有子查询在
FROM子句外使用变量或用户变量（如@var），否则创建失败 - 如果查询涉及多个表，建议显式写全字段别名，避免后续
SELECT *出现列名冲突
多表 JOIN 视图要小心字段歧义和 NULL 值传播
用视图封装 JOIN 是最常见场景，但也是出问题最多的地方。比如学生表 + 成绩表 + 课程表连查，一旦某条成绩记录缺失，整个学生行就可能因 INNER JOIN 被过滤掉，而使用者只看到“这个学生没数据”，却不知道是关联断裂导致的。
使用场景：报表统计、BI 工具直连、权限隔离层。
- 优先用
LEFT JOIN替代INNER JOIN，确保主表记录不丢失，再用COALESCE()处理空值 - 所有字段必须加表别名前缀，例如
s.name、c.class_name，否则CREATE VIEW可能报Column 'name' in field list is ambiguous - 聚合类视图（含
GROUP BY）默认不可更新，即使底层是单表也不行
WITH CHECK OPTION 不是可选项，而是控制更新边界的开关
视图支持 UPDATE / INSERT，但前提是它映射的逻辑允许反向写入。比如一个只查 salary > 5000 的视图，如果直接往里面 INSERT 一条 salary = 4000 的记录，MySQL 默认会拒绝——除非你没加 WITH CHECK OPTION，那它可能绕过检查，写进基表却不在视图结果里，造成数据“隐身”。
性能影响：开启 WITH CHECK OPTION 会让每次写入多一次条件校验，但换来的是数据一致性保障。
- 单表筛选视图强烈建议加上
WITH CHECK OPTION，防止脏数据混入 - 多表视图无法使用
WITH CHECK OPTION，MySQL 会报错ERROR 1369 (HY000): CHECK OPTION on updatable view is not supported - 修改已有视图时，
CREATE OR REPLACE VIEW不会保留原视图的WITH CHECK OPTION属性，必须显式重写
视图依赖基表结构，改表字段前务必检查 SHOW CREATE VIEW
视图本身不存数据，但它的生命线绑在基表上。今天给 users 表加了个 phone 字段，明天删了 email 字段——后者会让所有引用 email 的视图在查询时报错 Unknown column 'email' in 'field list'，而且这个错误不会在删字段时提示，只在第一次查视图才暴露。
容易被忽略的地方：视图的字段映射是静态快照，不是实时绑定。哪怕基表字段类型变了（比如 VARCHAR(50) 改成 VARCHAR(200)），只要名字不变，视图仍能运行；但字段删了或重命名，视图就立刻失效。
- 上线前执行
SHOW CREATE VIEW view_name，人工核对涉及的表和字段是否还存在 - 运维脚本批量改表结构时，应配套扫描
INFORMATION_SCHEMA.VIEWS查依赖关系 - 不要在视图定义里用
*，它会让字段变更更难追溯，也增加解析开销
