视图中用子查询易导致重复执行，因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 行是来自主表扫描，还是子查询反复执行累积的结果
真正难的不是语法能不能换，是确认「这个子查询在视图上下文里是否还保持幂等性和确定性」——它可能在单查时没问题，一放进视图被反复调用、被嵌套引用、被下游加条件，就暴露底层执行模型的裂痕。
