SQL视图中子查询不如JOIN稳定的原因

视图中用子查询容易导致重复执行——MySQL 5.7及更早版本不会物化相关子查询，每次调用都得重跑；而JOIN则更容易被优化器下推条件、稳定执行路径，语义也更清晰。

视图定义里用子查询容易触发重复执行

MySQL 5.7 及更早版本的视图展开机制，对相关子查询（DEPENDENT SUBQUERY）基本不做物化。什么意思呢？每次调用视图，子查询都会从头到尾重跑一遍。比如视图里写 SELECT id, (SELECT name FROM users u WHERE u.id = t.user_id) FROM orders t，外面再加个 WHERE status = 'paid'，优化器没法把 status = 'paid' 下推进子查询，结果就是子查询对 orders 表的每一行都执行一次。

• EXPLAIN 里 Extra 列出现 Using where; Using temporary，且 rows 值远高于实际订单数——这是典型信号。
• PostgreSQL 和 MySQL 8.0+ 虽然支持部分物化，但仅限非相关子查询；一旦子查询含有外层引用（比如 t.user_id），依然退化为逐行调用。
• 视图被嵌套调用时（比如另一个视图 SELECT * FROM v_orders 再 JOIN），问题会指数级放大。

JOIN 在视图中更容易被优化器重写和下推条件

视图定义里用 LEFT JOIN users u ON t.user_id = u.id，优化器能识别连接关系，把外层 WHERE 条件（如 u.status = 'active'）下推到 users 表扫描之前，还能利用 user_id 索引跳过无效匹配。

• JOIN 的执行路径更确定：驱动表、被驱动表、连接算法（Hash Join 或 Index Nested-Loop）全都能在 EXPLAIN 里看得清清楚楚。
• 即使视图被多次嵌套引用，优化器也大概率保留 JOIN 结构，不会“拆开再拼”。
• 但注意：INNER JOIN 可能意外过滤掉空关联数据，而原意可能是想保留主表所有行——这时必须用 LEFT JOIN，不能只看性能就换。

子查询在视图中对 NULL 和语义的处理更脆弱

视图里写 WHERE id NOT IN (SELECT order_id FROM refunds)，只要 refunds.order_id 有任意一个 NULL，整个条件就恒为 UNKNOWN，结果集直接变空；但等价的 LEFT JOIN refunds r ON o.id = r.order_id WHERE r.order_id IS NULL 不受 NULL 影响，行为可预测。

• NOT IN 子查询在视图中极易因数据变更突然“不返回任何行”，排查时很难联想到 NULL 问题。
• 标量子查询（如 (SELECT MAX(time) FROM log l WHERE l.order_id = o.id)）若无匹配行，返回 NULL 是明确语义；但改成 LEFT JOIN 后若忘记加 GROUP BY 或 ROW_NUMBER()，可能因一对多关系返回重复行或错误聚合值。
• 视图一旦发布给下游应用，这些语义差异就会固化，改写成本远高于普通查询。

视图字段依赖关系在子查询下更难追踪

当视图字段来自子查询（如 (SELECT COUNT(*) FROM items i WHERE i.order_id = o.id)），后续在该视图上再加 ORDER BY 或 GROUP BY，优化器无法将排序/分组下推到子查询内部，只能先展开全部行再计算，内存压力陡增。

• 而等价的 LEFT JOIN (SELECT order_id, COUNT(*) cnt FROM items GROUP BY order_id) i ON o.id = i.order_id，子查询已预聚合，外层操作直接作用于小结果集。
• 某些 ORM 或 BI 工具解析视图结构时，会把子查询字段识别为“不可索引列”，导致自动添加的过滤条件无法命中索引。
• 最麻烦的是调试：你看到视图返回了 100 行，但不知道这 100 行是来自主表扫描，还是子查询反复执行累积的结果。

真正难的不是语法能不能换，而是确认「这个子查询在视图上下文里是否还保持幂等性和确定性」——它可能在单查时没问题，一放进视图被反复调用、被嵌套引用、被下游加条件，就会暴露出底层执行模型的裂痕。