EXPLAIN出现type=ALL或Using temporary即表示已失控，主因是优化器在三张以上表JOIN时枚举退化、驱动表选错、索引缺失或统计失真，导致BNLJ回退、临时表落盘、I/O与CPU开销剧增。
EXPLAIN 出现 type=ALL 或 Using temporary 就该停手
这不是警告，是已失控的信号。MySQL 优化器在三张表以上 JOIN 时，对连接顺序的枚举会迅速退化——5 张表有 120 种合法顺序，但 optimizer_search_depth 默认只试前 6 种，剩下的靠猜。一旦 EXPLAIN 显示某张表的 type=ALL，说明它被当成了被驱动表却没走索引；若 Extra 列出现 Using temporary，代表中间结果必须落盘，I/O 和内存开销直接翻倍。
- rows 值远大于该表实际匹配行数 → 驱动表选错，退化成块嵌套循环（BNLJ）
-
join_buffer_size不够时，被驱动表会被反复扫描多次 - 哪怕加了 WHERE 条件，只要统计信息过期（
ANALYZE TABLE没跑），优化器仍可能误判“小表”
四表 JOIN 很容易触发 BNLJ 回退，而非你想象的 NLJ
MySQL 5.7/8.0 仅原生支持嵌套循环类算法：Simple Nested-Loop Join、Block Nested-Loop Join、Index Nested-Loop Join。后两者依赖索引和 buffer 大小。一旦 ON 字段缺失索引，或 join_buffer 装不下驱动表数据，就会从最优的 INLJ 回退到 BNLJ，甚至 SNLJ。这时复杂度不是 O(m·log n)，而是 O(m·n)。
- orders 表 100 万行，加了
WHERE create_time > '2026-05-01'后只剩 50 行 → 理论上该当驱动表 - 但 users 表没过滤条件、且没在
user_id上建索引 → MySQL 只能全表扫 users 匹配，每条 orders 数据都扫一遍 -
join_buffer_size默认才 256KB，远不够缓存 50 行订单 ID → 触发分批加载，users 表被扫 3–5 次
分布式或分库分表环境下，JOIN 根本不可用
如果用了 ShardingSphere、MyCat 或自研分库分表，跨库 JOIN 基本等于放弃。MySQL 本身不支持跨节点哈希连接，中间件要么广播查询（N 次单表查），要么禁止语法（如 ShardingSphere 的 sql-statement 拦截）。哪怕强行写，也会变成：先查库 A 的 orders，再把 user_id 列表发给库 B 查 users，再把 product_id 发给库 C 查 products —— 这本质已是应用层拼装，不如一开始就拆开。
- 分片键不一致时，JOIN 无法路由到同一物理库，直接报错
ERROR 1105 (HY000): Cannot route datanode - 即使能路由，跨库数据传输量剧增，网络延迟成为瓶颈
- 中间件通常禁用
STRAIGHT_JOIN，你连强制顺序的权利都没有
替代方案不是“少写 JOIN”，而是“换地方做关联”
别纠结“能不能让四表 JOIN 快起来”，要问“哪些数据真需要一次查完”。阿里推荐的路径很务实：主表 + 关键维度（1–2 张）先查，拿到 ID 列表后，用 WHERE id IN (...) 或批量 SELECT ... WHERE id = ? 拉其余维度，最后在应用层 hash join 组装。这看似多几次 RPC，实则更可控。
- 数据库 CPU 压力分散，写请求不受影响
- 每步可单独加缓存（如 Redis 缓存用户信息）
- 失败可重试局部步骤，而非整个 SQL 失败
- 避免因一张表慢拖垮全部，隔离性更好
真正难的不是拆 SQL，是识别哪些字段必须强一致性实时 JOIN，哪些可以容忍几秒延迟异步填充——这个判断比写索引还关键。
