MySQL不建议多表JOIN，主因是优化器在三张以上表关联时易选错驱动表、跳过索引、生成低效执行计划；EXPLAIN出现type=ALL、rows过大、Using temporary或Using filesort即表明已失控。
MySQL 不建议用过多 JOIN，核心原因不是语法限制，而是优化器在面对三张以上表关联时，解析路径数会爆炸式增长，极易选错驱动表、跳过索引、生成低效执行计划——这不是“可能慢”，而是“大概率失控”。
EXPLAIN 显示 type=ALL 或 rows 超大时，JOIN 已经失控
当 EXPLAIN 输出中某张表的 type 是 ALL 或 index，且 rows 列远超该表过滤后的真实数据量，说明优化器没走索引嵌套循环（NLJ），退化到了块嵌套循环（BNLJ）甚至更差的路径：
- 被驱动表缺失
ON字段索引 → 强制全表扫描匹配，复杂度从 O(log N) 回退到 O(N) - 优化器误判“小表”：比如
orders表总行数 100 万，但加了WHERE create_time > '2026-05-01'后只剩 50 行；而users表总行数 10 万，但没加过滤条件 → 优化器仍可能选users当驱动表 -
join_buffer_size不足时，BNLJ 会反复分批加载驱动表数据，导致被驱动表被扫描多次
三张表 JOIN 就可能触发临时表（Using temporary）
一旦 EXPLAIN 的 Extra 列出现 Using temporary，基本意味着 MySQL 放弃了流式合并，转而把中间结果写入内存或磁盘临时表：
- 内存临时表受
tmp_table_size和max_heap_table_size限制，超限自动落盘 → I/O 暴增 - 临时表无法复用已有索引，后续
ORDER BY或GROUP BY只能走filesort - 多表 JOIN 中只要有一张表参与
ORDER BY或聚合，就极容易触发该行为，和字段是否索引无关
JOIN 表数超过 4 张，优化器路径搜索接近失效
MySQL 5.7/8.0 的优化器对 N 表 JOIN 的合法连接顺序枚举上限是 N!，但实际只评估前若干种组合（由 optimizer_search_depth 控制，默认为 6）。当表数 ≥ 5：
- 优化器不再穷举，改用贪心算法，大概率漏掉最优顺序
- 统计信息不准（
ANALYZE TABLE没及时更新）时，误判更严重 - 即使你手写
STRAIGHT_JOIN强制顺序，也挡不住 BNLJ 或哈希构建失败后的回退 - 阿里《Java 开发手册》禁三表 JOIN，不是拍脑袋——实测四表 JOIN 在 100 万级数据下，90% 场景响应超 2s
替代方案比硬扛 JOIN 更可控
与其调优一条 5 表 JOIN，不如拆成两步：
- 先查主表 + 一两张关键关联表（如
orders JOIN order_items），拿到 ID 列表或轻量结果 - 用
WHERE id IN (…)或批量SELECT … WHERE id = ?拉取其余维度数据（如用户、商品、地址） - 应用层做 hash join 组装，内存可控、可并行、可缓存
- 若维度表变化少（如地区、状态码），直接冗余字段或建宽表，彻底消灭实时 JOIN
真正难处理的从来不是“怎么写 JOIN”，而是当 EXPLAIN 里已经出现 Using temporary 和 Using filesort 时，还试图靠加索引或改写 ON 条件去硬刚——这时候该砍的不是 SQL，是关联逻辑本身。
