SQL OUTER JOIN 并非先内连接再补NULL，而是以驱动表逐行扫描并强制填充NULL：LEFT JOIN以左表为驱动表，RIGHT JOIN以右表为驱动表，FULL OUTER JOIN需两遍扫描或双哈希表合并，NULL是语义强制而非事后修补，性能关键在驱动表选择与被驱动表ON字段索引。

SQL OUTER JOIN 的执行逻辑不是先做 INNER JOIN 再补 NULL，而是基于驱动表（左表或右表）逐行扫描，对每行在被驱动表中查找匹配项；没找到就用 NULL 填充整行，确保驱动表所有记录都出现在结果中。

LEFT JOIN 的实际执行流程

以 SELECT * FROM A LEFT JOIN B ON A.id = B.a_id 为例：

• 数据库将表 A 作为驱动表，按其物理顺序或索引顺序逐行读取
• 对 A 的每一行，根据 B.a_id 索引（如果有）查找 B 中所有满足 a_id = A.id 的行
• 若找到匹配行，将 A 行与每个匹配的 B 行组合输出（一对多时产生多行）
• 若未找到任何匹配，仍输出该 A 行，并为 B 的所有列填充 NULL

RIGHT JOIN 和 FULL OUTER JOIN 的差异点

RIGHT JOIN 本质是把右表当驱动表，逻辑与 LEFT JOIN 对称；FULL OUTER JOIN 则需两遍扫描或哈希合并：

• 多数引擎会先算 LEFT JOIN（保留左表全集），再找出右表中未被匹配的行（即 B LEFT JOIN A WHERE A.id IS NULL），最后 UNION 两者
• 部分优化器可能用双哈希表：分别构建 A、B 的哈希表，遍历 A 找匹配并标记已覆盖，再遍历 B 输出未覆盖行 + NULL 左侧字段
• 不支持 FULL JOIN 的数据库（如 MySQL）需用 LEFT + RIGHT + UNION 模拟，注意去重和 NULL 处理

N

ULL 填充不是“事后补全”，而是语义强制

OUTER JOIN 的 NULL 不是执行完 INNER 后追加的修补操作，而是连接算法本身的设计结果：

• 驱动表某行无匹配时，连接结果集必须包含该行，但被驱动表无真实数据可填，所以标准规定填 NULL
• 即使被驱动表有 WHERE 条件（如 WHERE B.status = 'active'），也只影响匹配过程，不改变“无匹配就填 NULL”的行为
• 若在 ON 条件后加 WHERE 对被驱动表字段判非 NULL（如 WHERE B.id IS NOT NULL），会把原本的 OUTER 效果退化为 INNER JOIN

性能关键：驱动表选择与索引利用

OUTER JOIN 性能瓶颈通常不在 NULL 填充，而在匹配查找效率：

• 驱动表应尽量小（行数少、过滤后更少），减少外层扫描次数
• 被驱动表的 ON 字段必须有高效索引（最好是前导列），否则每行都要全表扫 B
• JOIN 后再加复杂 WHERE 或聚合，可能使优化器放弃嵌套循环，改用临时表+排序，实际执行计划需用 EXPLAIN 验证