如何通过将不常用的表为视图来简化SQL中深度LEFT JOIN的优化？

本文共计867个文字，预计阅读时间需要4分钟。

在多个LEFT JOIN操作中，若连接的表数据量较大，MySQL很容易退化成嵌套循环（NLJ），导致扫描行数大幅增加。例如，对`orders`、`users`、`addresses`和`logistics`四张表进行LEFT JOIN，若每张表扫描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，导致先全量关联再过滤。所以最稳的方式，是把“过滤逻辑”直接写死在视图定义里，哪怕略显僵硬。