MySQL执行多表联查时，Nested-Loop Join算法是怎么运作的？-mysql教程-PHP中文网

mysql多表联查的nlj按驱动表→被驱动表链式嵌套执行，驱动表由优化器基于预估行数决定（explain首行为驱动表），被驱动表是否走索引取决于on字段是否有有效索引（含最左前缀与类型匹配），三表及以上仍为逐层嵌套而非全排列。

mysql执行多表联查时，nested-loop join算法是怎么运作的？

MySQL执行多表联查时，Nested-Loop Join（NLJ）不是按SQL书写顺序嵌套，而是由优化器选定驱动表后，严格按「驱动表 → 第一被驱动表 → 第二被驱动表」链式展开，每层只做单次外层行到内层匹配的映射。

EXPLAIN第一行就是驱动表，别信SQL写法顺序

很多人以为SELECT * FROM t1 JOIN t2 ON ... JOIN t3 ON ...里t1一定是驱动表，其实不是。优化器根据WHERE过滤后的预估行数选驱动表：EXPLAIN输出中id相同、select_type为SIMPLE的行，从上到下就是执行顺序——第一行才是驱动表。

LEFT JOIN左表强制为驱动表，RIGHT JOIN右表强制为驱动表，但INNER JOIN完全由优化器定
如果t1有WHERE status = 'active'而t2没条件，即使t1更大，优化器也可能选t2当驱动表（因为t1过滤后只剩10行）
type字段是const或eq_ref，说明驱动表已精准定位，这是NLJ最稳的起点

被驱动表走不走索引，只看ON字段有没有有效索引

NLJ本身不要求索引，但MySQL实际执行时，只要被驱动表的ON字段有可用索引（主键、唯一索引、普通索引），就会自动降级为Index Nested-Loop Join，避免全表扫描。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

ON u.id = o.user_id，若orders.user_id无索引，type会是ALL，可能触发BNL甚至性能雪崩
复合索引必须满足最左前缀：INDEX(user_id, status)能用于ON user_id = ?，但ON status = ?不能用
隐式类型转换直接废索引：比如user_id是INT，但写成ON user_id = CAST('123' AS CHAR)，索引失效

三表JOIN不是全排列，是链式嵌套，中间结果不物化

MySQL不会把三张表一起哈希或一次性全连，而是严格按链式结构执行：t1 → t2 → t3，且中间结果不缓存（除非显式用JOIN BUFFER）。

伪代码近似：foreach r1 in t1 { foreach r2 in t2 where r2 matches r1 { foreach r3 in t3 where r3 matches r2 { output } } }
t3被扫描次数 = t1与t2匹配后的总行数 × 每次匹配的t3扫描开销
如果t1 × t2结果集有5000行，而t3没索引，等于扫t3 5000遍——这个放大效应容易被忽略