sql join面试核心是根据业务场景准确选型、处理空值、防笛卡尔积与重复；inner join取交集，left join保左表全量，自连接需别名区分，多表join须按主从顺序显式书写。
SQL JOIN 是面试中最常考的多表关联操作，核心不在语法本身，而在于能否根据业务场景准确选择连接类型、处理空值、避免笛卡尔积和重复数据。
INNER JOIN：只保留匹配行，最常用也最容易被误用
当题目要求“查出有订单的客户”“统计每个部门的员工数（部门必须有员工）”，本质就是取交集。注意：一旦某表字段为 NULL，该行不会出现在结果中。
- 别名必须明确，尤其多表时用 t1/t2 或表缩写，避免列名冲突
- ON 条件写清楚关联字段，不要把过滤条件（如 status = 'active'）错放 ON 中——除非是外连接的特殊需求
- 示例：查订单金额大于 100 的客户姓名和订单号，需先 INNER JOIN 客户与订单表，再 WHERE 过滤金额
LEFT JOIN：以左表为主，右表缺失补 NULL，高频考点
题目出现“列出所有客户，包括没下过订单的”“显示商品及对应销量（无销量显示 0）”，基本锁定 LEFT JOIN。关键在理解“左表全量 + 右表匹配或 NULL”。
- WHERE 条件若对右表字段做非 NULL 判断（如 WHERE o.order_id IS NOT NULL），会退化为 INNER JOIN 效果，务必警惕
- 统计类需求常用 COALESCE(SUM(o.amount), 0) 或 COUNT(o.order_id) 而非 COUNT(*)，后者会把 NULL 行也算进去
- 多层 LEFT JOIN 时，后一个 JOIN 的 ON 条件只能引用前序表，不能跨跳引用更早的左表字段（除非子查询或 CTE）
自连接与多表 JOIN：理清逻辑层级，避免交叉污染
查“每个员工的直属上级姓名”“找出比自己工资高的同事”属于典型自连接；“客户-订单-订单明细-商品”则是四表关联。难点不在写法，在建模意识。
- 自连接必须给同一张表起不同别名（e.g., e 为员工，m 为经理），ON 条件明确层级关系（e.manager_id = m.id）
- 多表 JOIN 建议按主从顺序书写：主实体（如 customer）→ 一级关联（orders）→ 二级关联（order_items）→ 三级关联（products）
- 避免隐式 JOIN（逗号分隔 FROM），一律用显式 JOIN + ON，可读性高且不易漏条件
常见陷阱与调试技巧
面试官常通过加干扰条件考察细节把控能力。遇到结果条数异常、NULL 大量出现、性能骤降，优先检查这些点：
- JOIN 类型是否与语义一致（要“全部客户”却用了 INNER）
- ON 和 WHERE 混用导致逻辑错误（尤其外连接中对右表字段加 WHERE）
- 关联字段类型不一致（如 VARCHAR 和 INT 比较，可能隐式转换失败）
- 缺少必要索引，大表 JOIN 时执行计划走嵌套循环而非哈希连接
- 用 SELECT * 测试时字段重复（如两张表都有 id），改用明确列名 + 别名
真正拉开差距的，不是写出语法正确的 JOIN，而是能结合业务目标判断该不该连、连哪几张、怎么连才既准确又高效。
