mysql视图中子查询必须分场景使用：where中允许但性能差，from中mysql 5.6+报错1349，select列表中相关子查询导致n×m次扫描，应优先用join替代。
能，但必须分清子查询用在哪儿、怎么用，否则轻则查不出数据，重则整张表卡死。
WHERE 里放子查询：语法通，但每次查都重算
比如 CREATE VIEW v_active_users AS SELECT * FROM users WHERE id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5)，MySQL 5.7+ 和 PostgreSQL 都允许创建。但问题在于：每次查 v_active_users，那个子查询都会完整执行一遍，且无法下推外部条件。
- 查单个用户时仍扫描全量
orders表 -
SELECT * FROM v_active_users WHERE status = 'locked'不会提前过滤users表，而是先算完所有活跃用户再筛状态 -
EXPLAIN显示rows极大，Extra出现Using temporary
替代方案更稳：CREATE VIEW v_active_users AS SELECT u.* FROM users u LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id WHERE o.cnt > 5 —— 把聚合逻辑提前物化，让优化器有机会复用中间结果。
FROM 中的子查询（派生表）：MySQL 5.6 是硬伤
像 SELECT * FROM (SELECT id, name FROM customers WHERE country = 'CN') AS cn_customers 这类非相关子查询，在 PostgreSQL、SQL Server、MySQL 8.0+ 中都支持，优化器也能较好处理。但在 MySQL 5.6 及更早版本中，直接报错：ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause。
- 必须显式加别名，否则报
ERROR 1248 (42000): Every derived table must have its own alias - 含
LIMIT、用户变量@var或窗口函数时，MySQL 视图创建会失败 - PostgreSQL 对嵌套层级没硬限制，但超过 3 层后
EXPLAIN可能难以看清实际执行路径
SELECT 列表里的标量子查询：N × M 次扫描
例如 SELECT id, name, (SELECT COUNT(*) FROM orders WHERE user_id = users.id) AS order_count FROM users，语法完全合法，但这是典型的相关子查询——查 1000 行用户，就触发 1000 次独立的 orders 表扫描。
- 外部加
ORDER BY order_count LIMIT 10，数据库仍得算满 1000 个值，无法跳过 - SQL Server 中若视图未加
SCHEMABINDING，优化器甚至可能放弃下推谓词 - 真正需要聚合统计时，优先用
LEFT JOIN替代；若必须保留语义，PostgreSQL 可考虑LATERAL，比相关子查询更可控
最易被忽略的一点：视图不存数据，每次查询都会展开重算。哪怕子查询看起来“只算一次”，它在执行计划里就是反复出现的节点——性能瓶颈往往藏在看似无害的括号里。
