MySQL 5.7及更早版本视图确实禁止子查询，仅8.0+支持FROM子句中的派生表；标量子查询、WHERE子查询等仍受限，可用JOIN重写、中间视图或存储函数绕过。
MySQL 5.7 及更早版本中视图确实不能包含子查询
这是真实存在的限制，不是语法写错了。MySQL 在 CREATE VIEW 时会对定义语句做静态解析，5.7 及之前版本明确禁止在视图定义的 SELECT 列表、WHERE、HAVING 或 ORDER BY 中直接使用子查询（包括标量子查询和派生表）。错误提示通常是：ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause 或类似变体。
根本原因在于：早期 MySQL 的视图实现不支持将子查询“内联展开”到外部查询中，导致优化器无法生成确定的执行计划，也难以做权限校验和可更新性判断。
- MySQL 5.7 中，
(SELECT ...)出现在SELECT列表（如SELECT (SELECT name FROM users WHERE id = t.user_id) AS user_name）会被拒绝 -
FROM (SELECT ...) AS t这类派生表写法在视图中也不被允许 - 但
JOIN子查询改写成等价的连接（INNER JOIN/LEFT JOIN）后，通常就能通过
MySQL 8.0+ 允许部分子查询，但仍有关键限制
8.0 引入了对派生表的物化优化，并放宽了视图定义约束——但仅限于 FROM 子句中的派生表（即 FROM (SELECT ...) AS t），其他位置仍受限。
也就是说，以下写法在 MySQL 8.0+ 中是合法的：
CREATE VIEW active_orders AS SELECT o.id, o.amount, u.name AS user_name FROM orders o LEFT JOIN (SELECT id, name FROM users WHERE status = 'active') u ON o.user_id = u.id;
但这些依然会报错：
-
SELECT id, (SELECT COUNT(*) FROM logs l WHERE l.order_id = o.id) AS log_count FROM orders o（标量子查询在SELECT列表） -
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE role = 'vip')（子查询在WHERE） -
SELECT * FROM (SELECT * FROM orders ORDER BY created_at DESC LIMIT 10) t（派生表嵌套过深或含LIMIT，部分场景仍被拒）
绕过限制的三种实操替代方案
不升级 MySQL 或无法重构业务逻辑时，优先考虑这几种落地方式：
- 用
JOIN重写标量子查询：把(SELECT name FROM users WHERE id = o.user_id)改为LEFT JOIN users u ON o.user_id = u.id，再选u.name - 拆成两步：先建一个中间视图（不含子查询）封装子查询逻辑，再在主视图中引用它（注意：MySQL 视图不能递归引用自身，但允许 A → B → C 链式引用）
- 用存储函数封装子查询逻辑：例如创建
FUNCTION get_user_name(user_id INT) RETURNS VARCHAR(100)，然后在视图中调用get_user_name(o.user_id)；缺点是函数执行不可下推，可能影响性能，且需确保SQL SECURITY DEFINER权限正确
真正容易被忽略的兼容性细节
即使你用的是 MySQL 8.0，视图里用了派生表，上线后也可能出问题：
- 如果视图定义中派生表包含
ORDER BY+LIMIT，MySQL 可能拒绝创建（除非外层也有ORDER BY） - 视图一旦包含派生表，就自动变为“不可更新”（
INSERT/UPDATE/DELETE失败），这点和普通视图行为不同 - 某些 ORM（如 Django 的
raw()或 SQLAlchemy 的text()）在拼接查询时，若动态注入字段名，可能意外触发子查询语法，导致视图失效而不报错
