LEFT JOIN 不会自动避免笛卡尔积，必须显式书写正确 ON 条件；漏写或错写会导致结果爆炸或语义错误，如 WHERE 中过滤右表字段会使 LEFT JOIN 退化为 INNER JOIN。
LEFT JOIN 本身不会自动避免笛卡尔积；漏写 ON 或写错条件，照样爆炸式膨胀。
每个 LEFT JOIN 后必须跟有效的 ON 子句
MySQL 8.0+ 在缺少 ON 时直接报 ERROR 1064，但旧版（如 5.7）或宽松 SQL mode 可能静默退化为 CROSS JOIN——也就是笛卡尔积。比如 orders 有 1 万行、customers 有 5 千行，结果就是 5000 万行。
常见错误写法：
SELECT * FROM orders LEFT JOIN customers;
正确写法必须显式声明关联逻辑：
-
ON orders.customer_id = customers.id—— 字段名拼写、大小写、NULL 安全性都要核对 - 可用
USING (customer_id)替代，但要求两表字段名完全一致且都存在 - 子查询作右表时，仍需
ON关联，不能依赖外层 WHERE
WHERE 放错位置会让 LEFT JOIN 失效
这是最隐蔽也最常踩的坑：ON 定义“怎么连”，WHERE 是“连完再筛”。把右表的业务条件（比如状态、时间）写在 WHERE 里，等于把本该保留的 NULL 行全过滤掉了，效果等同于 INNER JOIN。
错误示例：
SELECT o.order_id, c.name FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active';
正确做法是把右表条件移到 ON 中：
ON o.customer_id = c.id AND c.status = 'active'- 若需保留所有订单、只关联活跃客户，就该这么写
- 若需先关联再筛客户状态，那就要明确接受
NULL的语义
关联字段重复值或 NULL 会隐式放大结果集
即使 ON 正确，数据质量问题也会导致“伪笛卡尔积”：不是组合爆炸，而是意外多行。
典型场景：
-
orders.customer_id有重复值（比如同一客户下了 50 单），而customers.id对应 3 条记录（历史重名/软删除未清理）→ 输出 150 行 -
orders.customer_id含大量NULL，它们在JOIN中不匹配任何客户，但不会报错；若后续WHERE过滤了c.id IS NOT NULL，就又变相转成内连接 - 快速检查：用
SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id HAVING COUNT(*) > 10找高频外键
多表 LEFT JOIN 时，每对相邻表都要有业务意义的 ON
三张表连查（比如 orders → customers → addresses），不能只写第一个 ON 就完事。第二个 LEFT JOIN 必须独立定义它和前一个结果的关系。
错误写法：
SELECT * FROM orders o LEFT JOIN customers c ON o.customer_id = c.id LEFT JOIN addresses a; -- ❌ 缺少 ON！
正确写法要明确每一步的连接依据：
LEFT JOIN addresses a ON c.id = a.customer_id- 别指望数据库“自动推断”地址属于哪个客户——它只会按规则执行
- 如果地址表用的是
user_id而非customer_id，字段名不一致就得手动对齐
复杂点在于：连接顺序、NULL 传播、重复值叠加，这些都不会报错，但结果可能和预期差十倍。动手前先用小数据集验证中间结果，比调通后发现数据翻了三倍再回头查强得多。
