MySQL视图是保存的SELECT语句，每次查询实时执行，不缓存；5.7及以前不支持FROM子句含子查询，需改用临时表、CTE（8.0+）或展开JOIN；OR REPLACE会覆盖视图但丢失CHECK OPTION等设置；多表JOIN视图不可更新；性能取决于底层查询，须用EXPLAIN评估。
MySQL 视图不是一张真实存数据的表，而是一条被保存下来的 SELECT 语句。每次你查它，MySQL 都会重新执行那条语句，从基表里实时拉数据 —— 所以它永远“新鲜”，但也不缓存、不加速查询本身。
为什么 CREATE VIEW 会报错 “View's SELECT contains a subquery in the FROM clause”？
MySQL 5.7 及更早版本不支持在视图定义的 FROM 子句里直接写子查询（比如 SELECT * FROM (SELECT id, name FROM users) AS t）。这不是语法错误，是引擎限制。
- 改用临时表或物化逻辑：把子查询结果先落成普通表，再基于该表建视图
- 升级到 MySQL 8.0+：支持 CTE（
WITH子句），可改写为WITH t AS (...) SELECT * FROM t - 合并逻辑：把子查询展开成 JOIN 或 WHERE 条件，避免嵌套
FROM
CREATE VIEW 时加不加 OR REPLACE 有什么实际影响？
不加 OR REPLACE，如果同名视图已存在，命令直接失败；加了则静默覆盖 —— 看似方便，但容易误删已有权限配置或破坏依赖它的应用逻辑。
- 生产环境建议显式
DROP VIEW IF EXISTS view_name+ 新建，留操作痕迹 -
OR REPLACE适合开发阶段快速迭代，但注意它不会重置视图的CHECK OPTION或算法（ALGORITHM）设置 - 若原视图有
WITH CHECK OPTION，新语句没写，覆盖后该约束就丢了
多表 JOIN 的视图能更新吗？
绝大多数情况下不能。只要视图定义里出现 JOIN、GROUP BY、DISTINCT、聚合函数（COUNT()、SUM()）、子查询、常量列，MySQL 就标记该视图为“不可更新” —— 即使你只 UPDATE 其中一个基表的字段，也会报错 Can not modify more than one base table through a join view。
- 单表视图（无计算、无 JOIN）默认可更新，但需确保
SELECT列都来自同一张基表且不含表达式 - 想绕过限制？别依赖视图更新，直接操作底层表；或者用存储过程封装写逻辑
- 检查是否可更新：查
INFORMATION_SCHEMA.VIEWS表里的IS_UPDATABLE字段，值为YES才真能改
真正容易被忽略的点是：视图的性能完全取决于它背后的 SELECT。一个没加索引的 JOIN 在视图里照常慢，而且你可能在应用层查 SELECT * FROM my_view 时根本意识不到它正扫三张大表。建之前，务必用 EXPLAIN 跑一遍原始语句。
