SQL JOIN 不是“自动配对”，而是数据库按具体算法一步步执行的物理过程。核心在于：先选驱动表，再用某种匹配策略扫描被驱动表，最后按 JOIN 类型决定是否补 NULL。
JOIN 的三步逻辑本质
虽然 SQL 语义上写的是 LEFT JOIN 或 INNER JOIN，但数据库实际执行时，会隐式走以下逻辑路径：
- 生成逻辑笛卡尔积框架：不是真建出全部组合，而是以该结构为参照，规划匹配范围；
-
基于 ON 条件做逐行匹配：驱动表每取一行，就在被驱动表中查找满足
ON 左字段 = 右字段的行； - 按 JOIN 类型组装结果：INNER 只留双方都有的；LEFT 保留驱动表全量，右表无匹配则填 NULL。
主流执行算法及其适用场景
数据库优化器会根据数据量、索引、字段类型等，自动选择最合适的底层算法：
- 嵌套循环连接（Nested Loop Join）：小表作驱动表时默认首选。外层扫驱动表，内层对每行去被驱动表查匹配——若被驱动表 JOIN 字段有索引，就走 Index Nested-Loop Join，大幅减少扫描行数；
- 哈希连接（Hash Join）：适合大表等值 JOIN。先把小表构建哈希表（键=JOIN字段），再逐行扫描大表，用哈希查找替代遍历，避免磁盘随机 I/O；
- 排序合并连接（Sort Merge Join）：当两张表的 JOIN 字段本身已有序（如主键或有对应索引），数据库可能跳过哈希建表开销，直接归并扫描，边排边比。
LEFT JOIN 的特殊执行要点
LEFT JOIN 的“左表全保留”不是靠后期补数据，而是在匹配阶段就强制保障：
- 驱动表固定为左表，逐行取出后，无论是否在右表找到匹配，这一行都必须进入结果集；
- 右表匹配失败时，对应字段不丢弃，而是统一置为 NULL —— 这个动作发生在结果组装阶段，而非过滤阶段；
- 如果右表 JOIN 字段无索引，又没走 Hash/Sort Merge，就会退化为全表扫描 × 左表行数，性能断崖下跌。
影响执行效率的关键因素
真正决定 JOIN 快慢的，往往不是写法，而是这几个可干预点：
- 驱动表选择是否合理：优先让过滤后结果集更小的表当驱动表，而不是看原始行数；
- 被驱动表 JOIN 字段必须有索引：这是 Nested Loop 能高效运行的前提；
-
避免 ON 条件中对字段使用函数：比如
ON YEAR(a.date) = YEAR(b.date)会让索引失效； -
留意 NULL 值参与比较的逻辑陷阱：如
ON a.id = b.id中任一为 NULL，结果为 UNKNOWN，不会匹配成功——这和直觉不同，但符合 SQL 三值逻辑。
