视图是封装复杂查询的虚拟表，创建时需避免字段重复、别名缺失等错误，且SELECT须合法；性能取决于底层查询优化；仅满足条件的视图才可更新；应定期维护以保障可维护性。
视图能直接把多表 JOIN、聚合、子查询等“写死”成一张虚拟表，后续查它就和查普通表一样简单，不用每次重写长 SQL。
CREATE VIEW 语句怎么写才不报错
常见错误是字段名重复、别名缺失、或用了不能被视图封装的操作（比如临时表、变量、LIMIT 在某些旧版本中）。
-
CREATE VIEW后面必须跟一个合法的SELECT查询，不能带ORDER BY（除非配合LIMIT，但 MySQL 8.0+ 允许带ORDER BY，执行时会被忽略） - 所有列必须有明确名字：如果
SELECT中有表达式（如score * 1.2），务必用AS指定别名，否则会报ERROR 1351: View's SELECT contains a '...' that is not allowed - 避免在视图定义里引用未授权的表——即使你当前有权限，视图创建后由其他用户调用时可能失败
- 示例正确写法：
CREATE VIEW student_score_summary AS SELECT s.name, c.class_name, AVG(sc.score) AS avg_score FROM students s JOIN classes c ON s.class_id = c.id JOIN scores sc ON s.id = sc.student_id GROUP BY s.id, c.class_name;
视图查出来慢，是不是不能用
不是不能用，而是得看底层查询有没有优化。视图本身不缓存结果，每次查都重新执行原 SELECT，所以性能完全取决于那个查询是否高效。
- 先对视图对应的原始
SELECT执行EXPLAIN，确认是否走了索引、有没有全表扫描 - 如果涉及多表 JOIN，确保关联字段（如
student_id、class_id）在基表上有索引 - MySQL 默认使用
TEMPTABLE算法处理含聚合或 DISTINCT 的视图，这比MERGE算法慢；可通过ALGORITHM = MERGE强制合并（仅适用于可合并的查询） - 不要嵌套太深：视图 A 基于视图 B，B 又基于视图 C —— 这种链式依赖会让优化器放弃合并，性能明显下降
为什么 UPDATE 视图有时失败
视图默认不可更新，只有满足特定条件才能支持 INSERT/UPDATE/DELETE，否则会报 ERROR 1394: Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger 或更常见的 ERROR 1395: Can't update table 'xxx' in select list。
- 单表视图且不含聚合、
DISTINCT、GROUP BY、子查询、计算列，通常可更新 - 多表 JOIN 视图只能更新其中一个基表，且必须明确指定目标表的字段（不能混用别名或表达式）
- 加
WITH CHECK OPTION后，插入/更新数据必须满足视图的WHERE条件，否则被拒绝 - 例如：
CREATE VIEW active_users AS SELECT id, name, email FROM users WHERE status = 'active' WITH CHECK OPTION;，之后INSERT INTO active_users VALUES (100, 'test', 't@x.com')成功，但插入status = 'inactive'就会失败
真正麻烦的不是语法，而是视图背后那条 SELECT 的可维护性——改一个字段名，所有依赖它的视图都得同步更新；加个新业务条件，可能得重写整个逻辑。别把它当成“一劳永逸”的捷径，而要当作需要定期 review 的查询契约。
