INNER JOIN 不是默认选项，因它会丢弃左表无匹配的记录，导致“空关联”数据丢失；LEFT JOIN 中 ON 与 WHERE 位置决定结果生死；JOIN 字段必须建索引，外键不等于索引。
因为几乎所有真实业务接口都依赖多表关联查询，不理解 JOIN 就等于不会写生产级 SQL。
INNER JOIN 为什么不是“默认选项”？
很多新人一写多表就用 INNER JOIN，结果上线后发现订单查不出来——因为用户没下过单、商品没被上架、地址没填全。这些“空关联”在业务中极其常见。INNER JOIN 会直接过滤掉左表中无匹配的记录，不是“查不到”，是“主动丢弃”。
- 适用场景：明确只要双方都存在的数据，比如「已支付且有物流单号的订单」
- 风险点：WHERE 条件里混用右表字段（如
WHERE order_status = 'paid'）会把 LEFT JOIN 变成事实上的 INNER JOIN - 性能提示：数据库通常优先用哈希连接或嵌套循环，但若 ON 字段没索引，小表驱动大表时可能慢十倍以上
LEFT JOIN 后 WHERE 和 ON 的位置决定结果生死
这是面试必挖坑点：ON 是关联逻辑，WHERE 是最终筛选。把本该写在 ON 里的条件错放到 WHERE，LEFT JOIN 就失效了。
- 正确写法：
LEFT JOIN order_item ON order.order_id = order_item.order_id AND order_item.quantity > 0 - 错误写法：
LEFT JOIN order_item ON order.order_id = order_item.order_id WHERE order_item.quantity > 0—— 这会过滤掉所有 quantity ≤ 0 的订单行，包括原本该保留的 NULL 行 - 调试技巧：先去掉 WHERE，SELECT 出所有字段，看 NULL 是否按预期出现；再逐步加条件验证
JOIN 字段没索引，查询可能从毫秒变秒级
哪怕表只有几万行，user_id 上没索引，LEFT JOIN orders ON users.user_id = orders.user_id 就可能触发全表扫描。优化器不会自动给你建索引，它只会告诉你“很慢”。
- 必须检查：所有
ON子句中的字段，是否至少有一侧建了索引 - 复合索引注意顺序：如果常写
ON a = x AND b = y，索引应为(a, b)，而不是(b, a) - 外键不等于索引：声明
FOREIGN KEY不会自动创建索引，MySQL 8.0+ 除外，但旧版本和 PostgreSQL 都需手动CREATE INDEX
真正难的不是语法，而是判断“这一行该不该出现在结果里”——这取决于业务语义，而不是 SQL 关键字。很多人能写出语法正确的 JOIN，却在需求变更时改错一行条件，导致资损或漏单。这才是面试官盯住 JOIN 不放的原因。
