MySQL视图在5.7及之前不支持子查询是设计限制而非bug，因优化器需内联展开视图定义，而子查询会破坏可更新性、权限推导与执行计划生成；8.0仅放宽非关联简单派生表限制。
MySQL 视图不支持子查询，不是 bug，而是早期版本（5.7 及之前）的明确限制——CREATE VIEW 语句中若包含 SELECT 子查询（尤其是 FROM 子句中的派生表、WHERE 中的 IN (SELECT ...) 或 EXISTS (SELECT ...)），会直接报错 ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause 或类似提示。
MySQL 5.7 及更早版本视图禁止子查询的底层原因
核心在于视图定义必须能被“内联展开”：当查询引用视图时，MySQL 优化器需把视图定义原封不动地拼进外部 SQL，再统一生成执行计划。而子查询（尤其派生表）无法安全展开——它可能依赖外部列、影响权限推导、破坏可更新性判断，甚至让优化器无法确定扫描顺序和索引选择。
- 视图定义里出现
(SELECT ... FROM t1)作为表源，会被拒绝 -
WHERE id IN (SELECT id FROM t2)在视图定义中同样不被允许 - 哪怕子查询只返回常量（如
(SELECT 1)），老版本也一概禁止
MySQL 8.0+ 允许部分子查询，但仍有严格限制
8.0 引入了对派生表的物化控制和更成熟的视图展开逻辑，但仅放宽了 *FROM 子句中简单派生表* 的限制，且要求满足：子查询不能关联外部表、不能含聚合、不能用 ORDER BY（除非带 LIMIT）、不能是相关子查询。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- ✅ 允许：
CREATE VIEW v AS SELECT * FROM (SELECT id, name FROM users) AS u; - ❌ 仍禁止：
CREATE VIEW v AS SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE active = 1); - ❌ 仍禁止：
CREATE VIEW v AS SELECT t1.*, (SELECT COUNT(*) FROM t2 WHERE t2.t1_id = t1.id) cnt FROM t1;
替代方案优先级：JOIN > EXISTS > 应用层拆分
绝大多数业务场景下，子查询本就该被重写，而非强求放进视图。重点不是“怎么绕过限制”，而是“怎么写出真正高效、可维护的视图”。
- 用
LEFT JOIN+GROUP BY替代SELECT ..., (SELECT ...)类标量子查询 - 用
INNER JOIN或LEFT JOIN ... WHERE ... IS NOT NULL替代WHERE ... IN (SELECT ...) - 用
EXISTS替代IN时，注意它不能直接塞进视图定义——得先改写成JOIN形式再建视图 - 如果关联逻辑复杂或涉及多层过滤，宁可在应用层查一次主表 ID，再用
WHERE id IN (...)查辅表，也别在视图里硬塞子查询
最容易被忽略的坑：视图可更新性与子查询幻觉
有人以为“只要视图能创建出来，就能 UPDATE 或 INSERT”，但即使 MySQL 8.0 允许某些子查询形式，只要视图定义含任何不可更新结构（比如聚合、DISTINCT、UNION、或哪怕一个看似无害的派生表），整个视图就自动变成只读。而开发者往往在数月后第一次尝试 UPDATE v SET x=1 时才看到 ERROR 1471 (HY000): The target table v of the INSERT is not insertable-into ——此时再回头改视图，牵扯面已远超最初预期。
