LEFT JOIN 多层嵌套慢因MySQL易退化为嵌套循环，扫描行数乘积级增长；视图可隔离低频关联逻辑，缩小右表数据集并提升主查询可控性。
LEFT JOIN 多层嵌套为什么慢
多个 LEFT JOIN 连在一起，尤其是跨 3 张以上表、且右表数据量大时，MySQL 很容易退化成嵌套循环（NLJ），扫描行数呈乘积级增长。比如 orders LEFT JOIN users LEFT JOIN addresses LEFT JOIN logistics，哪怕每张表只扫 1 万行，中间结果也可能膨胀到上亿行——EXPLAIN 里 rows 列会明显跳高，Extra 出现 Using temporary; Using filesort 就是典型信号。
视图不是性能银弹，但能隔离低频关联逻辑
把不常用、高成本的 LEFT JOIN 拆进视图，核心作用不是提速，而是让主查询逻辑更轻、更可控：
- 主查询只查高频字段（如订单号、金额、状态），不触发视图中冗余的
JOIN，避免每次执行都拉取地址/物流等冷数据 - 视图定义可加
WHERE过滤（如只保留status IN ('shipped', 'delivered')），缩小右表参与关联的数据集 - 视图本身不存储数据，但可以独立建索引（在 MySQL 8.0+ 中，物化视图仍不支持，但基础视图 + 合理索引依然有效）
示例：把物流信息抽成视图
CREATE VIEW order_logistics_view AS
SELECT o.order_id, l.tracking_no, l.status, l.update_time
FROM `order` o
LEFT JOIN logistics l ON o.order_id = l.order_id
WHERE l.status IS NOT NULL OR o.order_status IN ('shipped', 'delivered');
什么时候该用视图拆分，而不是硬写 JOIN
满足以下任意一条，就值得拆：
- 某张右表只在报表或后台导出场景中才需要，日常接口查询完全不用它
- 右表无合适索引，且无法加（如第三方同步表、历史归档表）
- 右表字段多、更新频繁，但主查询只读其中 1–2 个字段，
SELECT *式LEFT JOIN造成大量回表 - 同一张右表被多个业务 SQL 重复
LEFT JOIN，视图可统一维护关联逻辑和过滤条件
反例：把用户表 users 拆进视图——它几乎每个订单查询都要用，且已有 user_id 索引，拆了反而增加一次视图解析开销。
必须同步做的三件事，否则视图没用
光建视图不等于优化。以下动作缺一不可：
- 确保视图中所有
JOIN字段都有索引，特别是右表的外键列（如logistics.order_id必须有索引） - 主查询调用视图时，仍要限制返回字段，禁止
SELECT * FROM order_logistics_view；只查真正需要的列 - 在视图定义里显式加
WHERE条件收缩右表范围，而不是依赖主查询的WHERE下推（MySQL 对视图的条件下推支持有限，尤其含LEFT JOIN时）
复杂点在于：视图里的 LEFT JOIN 一旦涉及多层，MySQL 仍可能放弃下推外部 WHERE，导致先全量关联再过滤。所以最稳的方式，是把“过滤逻辑”直接写死在视图定义里，哪怕略显僵硬。
