漏写ON条件必然触发笛卡尔积；需逐行检查每个JOIN后是否立刻紧跟着有效ON子句，警惕ON 1=1、字段未限定别名、类型不匹配等伪条件，并用EXPLAIN或COUNT(*) OVER(PARTITION BY)验证。
漏写 ON 条件不是“可能出错”，而是必然触发笛卡尔积——两万行表 × 三万行表 = 六亿行中间结果，内存打满、查询超时、线上告警全来。
怎么快速定位漏写的 ON？
别猜，直接扫：从 FROM 开始，逐行看每个 JOIN 关键字后面是否**立刻紧跟着** ON 或 USING。中间不能有换行、注释或空行隔开。
- 看到
LEFT JOIN customers后面没ON，就是它了 -
JOIN (SELECT ...)这种子查询也得有ON，不能以为“里面过滤了就不用连” - 老式逗号语法
FROM a, b必须靠WHERE补关联，缺a.id = b.a_id等价于没写 - 用
EXPLAIN看执行计划：MySQL 出现type: ALL+Extra: Using join buffer，PostgreSQL 出现Nested Loop (Join Filter: true)，基本坐实漏ON
ON 写了但无效，和没写一样
语法通过 ≠ 语义有效。恒真条件、字段未限定别名、类型不匹配，都会让 ON 形同虚设。
-
ON 1=1、ON t1.id = t1.id—— 显式放弃关联逻辑 -
ON user_id = user_id（没加表别名）→ 可能被解析成t1.user_id = t1.user_id，右表完全没约束 -
t1.id是BIGINT，t2.t1_id是VARCHAR→ 隐式转换导致索引失效，退化为全表扫描 - 字段含大量
NULL或重复值（如order_items.order_id有 50 条相同值）→ 单行左表拉出几十行，聚合前就已失真
LEFT JOIN 的 WHERE 和 ON 放错位置
这不是语法错误，但效果比漏 ON 更隐蔽：LEFT JOIN 变相退化成 INNER JOIN，且中间结果早已爆炸。
- 错误：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 先生成所有c.status IS NULL的组合，再干掉，白耗资源 - 正确：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 右表只拉活跃客户，源头控量 - 如果业务必须保留无客户的订单，
WHERE里绝不能出现c.xxx字段；要筛右表，就挪进ON，或先用子查询聚合
多表 JOIN 时“链断了”更难发现
三张表以上连接，不能只盯着首尾，每一对相邻表都得有真实业务意义的 ON 条件。中间断一环，数据库只能暴力匹配。
- 错误写法：
orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON orders.id = products.id→products和orders没业务关系，纯笛卡尔积 - 正确链路：
orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON order_items.product_id = products.id - 验证方法：对每个
JOIN后加COUNT(*) OVER (PARTITION BY 主表.id)，看某步后数值是否突增数十倍 - 复杂链建议拆成 CTE：
WITH order_items_agg AS (SELECT order_id, SUM(qty) AS total_qty FROM order_items GROUP BY order_id)，再跟主表连
真正危险的不是报错，而是静默返回错误结果——尤其在视图、报表或定时任务里。每次改 SQL，第一件事不是调逻辑，是盯住每个 JOIN 后有没有紧挨着的 ON，以及它是不是真的在约束两边。
