笛卡尔积必然由join条件缺失、错误或失效引发；须逐行检查每个join后是否紧接有效on子句，禁用on 1=1等伪条件，left join过滤必须放on内，多表连接前用子查询聚合控量，并用窗口函数验证膨胀。

每个 JOIN 后必须紧跟着有效的 ON 子句

漏写 ON 是笛卡尔积最直接、最高发的触发点。MySQL 8.0+ 会报 ERROR 1064，但旧版或 ORM（如 Django ORM、MyBatis 动态 SQL）生成的语句可能静默转为 CROSS JOIN，结果就是左表行数 × 右表行数。

常见错误写法：FROM orders JOIN customers（没 ON）、LEFT JOIN logs ON 1=1（伪条件）、JOIN users u ON u.id = u.id（自等式，无业务意义）。

• 逐行扫描 SQL，确认每个 JOIN 关键字后**立刻**跟 ON 或 USING，中间不能有换行、注释或空格干扰
• USING (id) 要求两表字段名完全一致且类型兼容，不是省事借口
• 老式逗号语法 FROM a, b 必须靠 WHERE 补关联，缺一个等值条件（如 a.id = b.a_id）就等于没写

LEFT JOIN 的过滤条件必须写进 ON，不能放 WHERE

这是线上最隐蔽也最常被踩的逻辑坑。放在 WHERE 看似一样，实际执行顺序完全不同：先全量配对（含大量 NULL），再过滤——中间结果早已膨胀，内存和 I/O 白耗。

错误写法：LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' → 把无匹配订单全踢掉，等效 INNER JOIN，还多跑一遍空匹配。

正确写法：LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active' → 只拉活跃客户，从源头控量。

• 只要业务要求保留左表所有行（比如“查全部订单，只附带活跃客户信息”），WHERE 中就绝不能出现右表字段（如 c.level、c.deleted）
• 如果右表字段允许 NULL，WHERE c.status IS NOT NULL 和 WHERE c.status = 'active' 效果不同，后者更严格
• 用 EXPLAIN 看执行计划：PostgreSQL 出现 Nested Loop (Join Filter: true)，MySQL 出现 type: ALL + Extra: Using join buffer，基本就是这问题

多表 JOIN 时检查“桥接链”是否断裂

三张及以上表连接，不能只确保首尾有关联，中间每一对相邻表都得有真实业务意义的 ON 条件。跳过中间实体强行连接，数据库只能暴力匹配。

典型错误：orders JOIN products ON orders.id = products.id（无此业务逻辑），中间 order_items 形同虚设，结果是 orders × products 行数。

正确链路：orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON order_items.product_id = products.id。

• 验证方法：对每个 JOIN 后加 LIMIT 5 查中间结果行数，某步突增数十倍，大概率断链
• 嵌套视图也要逐层检查——上层视图 JOIN 下层视图，下层视图本身若已漏 ON，问题照旧
• 中间表外键字段若为 NULL 或指向不存在记录（如 addresses.city_id 为空），整条链也会松动

子查询参与 JOIN 前必须控制输出粒度

子查询一旦出现在 FROM 或 JOIN 右侧，它就变成一张“临时表”，和外层表之间仍需有效关联。裸写 (SELECT * FROM order_items) 再 JOIN，等于把明细表原样摊开，一对多关系立刻爆炸。

错误写法：LEFT JOIN (SELECT * FROM payments) p ON 1=1（ON 1=1 等同于没限制）；LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) p ON o.id = p.order_id（但漏了 WHERE status = 'success'，无效支付也被聚合）。

• 一对多侧优先在子查询里聚合：(SELECT order_id, COUNT(*) cnt FROM order_items WHERE status = 'shipped' GROUP BY order_id)
• “一”侧表也做前置过滤：(SELECT id, name FROM customers WHERE status = 'active')
• 需要明细但只取最新一条？用 ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC) 筛，别让引擎自己猜
• MySQL 8.0.14+ 或 PostgreSQL 可考虑 LATERAL，避免子查询提前物化整个结果集

真正难的不是写对第一个 ON，而是当 JOIN 链超过三张表、其中两张还是日志类宽表时，你得同时盯住字段类型是否一致、索引是否生效、NULL 值是否污染关联、以及子查询里那行 WHERE deleted = 0 到底有没有写进去——这些细节不抠到业务逻辑层，笛卡尔积就在后台默默吃光内存。