MySQL在执行多表联查时是如何应用Nested Loop Join算法的？-mysql教程-PHP中文网

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

mysql在执行多表联查时是如何应用nested loop join算法的？

MySQL执行多表联查时，Nested-Loop Join（NLJ）不是“固定用某张表嵌套另一张”，而是按驱动表→被驱动表逐层展开，每层只做一次外层行到内层匹配的映射，且是否走索引完全取决于被驱动表的关联字段是否有可用索引。

驱动表怎么定：看EXPLAIN第一行，不是看SQL书写顺序

INNER JOIN里哪张表是驱动表，由优化器根据WHERE过滤后的预估行数决定，不是左写谁就是谁。LEFT JOIN左表强制为驱动表，RIGHT JOIN右表强制为驱动表——但即便如此，优化器仍可能调整被驱动表的访问方式。

EXPLAIN输出中，id相同、select_type为SIMPLE的行，从上到下就是执行顺序：第一行是驱动表，第二行是第一个被驱动表，第三行是第二个被驱动表（如果是三表JOIN）
如果type字段是const或eq_ref，说明驱动表已精准定位（如主键等值查询），这是NLJ最理想的起点
若驱动表本身rows预估很大（比如10万行），哪怕被驱动表有索引，整体NLJ代价也高——因为要跑10万次索引查找

被驱动表走不走索引：只看on字段有没有有效索引

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

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

例如ON u.id = o.user_id，若orders.user_id无索引，type会是ALL，触发BNL或性能雪崩；若有索引，type通常为ref或eq_ref
复合索引必须满足最左前缀：INDEX(user_id, status)能用于ON user_id = ?，但ON status = ?不能触发该索引
注意隐式类型转换：比如user_id是INT，但ON条件里写了CAST('123' AS CHAR)，索引直接失效

三表及以上JOIN：NLJ是链式嵌套，不是一次性全连

MySQL不会把三张表一起哈希或一次全排列，而是严格按驱动表→第一被驱动表→第二被驱动表的链式结构执行。中间结果不物化，也不缓存（除非用JOIN BUFFER）。

假设t1 JOIN t2 ON ... JOIN t3 ON ...，执行逻辑近似：

for each row r1 in t1:
    for each row r2 in t2 where r2 matches r1:
        for each row r3 in t3 where r3 matches r2:
            output (r1,r2,r3)