笛卡尔积必然发生于join条件缺失、写错或隐式失效时；须逐行检查每个join后紧接有效on条件，禁用on 1=1等伪条件，left join过滤必须放on内，多表连接前用子查询聚合控量，并用窗口函数验证膨胀。
笛卡尔积不是“可能出错”，而是只要 JOIN 条件缺失、写错或隐式失效，它就一定发生——而且往往在你看到结果前，数据库已经把内存和 I/O 耗光了。
检查每个 JOIN 后是否紧跟着有效的 ON 子句
漏写 ON 是最常见也最致命的问题。MySQL 8.0+ 会直接报 ERROR 1064，但旧版或 ORM 生成的 SQL 可能静默转为 CROSS JOIN。比如 FROM orders JOIN customers 没有 ON，结果就是 orders 行数 × customers 行数。
- 逐行扫描 SQL，确认每个
JOIN关键字后**立刻紧跟着**ON，不是WHERE，也不是空着 - 警惕伪条件：
ON 1=1、ON u.name = c.name（姓名重复率高，无业务约束力） - 老式逗号语法
FROM a, b必须靠WHERE补关联；缺一个字段等于没写，例如WHERE a.id = b.a_id
LEFT JOIN 的过滤条件必须写进 ON，不能放 WHERE
这是线上最常被踩的逻辑坑。放在 WHERE 里看似一样，实际执行顺序完全不同：先全量配对再过滤，中间结果已膨胀。
- 错误写法：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 把无匹配的订单全踢掉，等效INNER JOIN，且白跑一遍 NULL 匹配 - 正确写法：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 右表只拉活跃客户，从源头控量 - 如果业务需要保留所有订单，又只取 VIP 用户信息，
WHERE里绝不能碰c.level这类右表字段
用子查询先聚合再 JOIN，别让明细表裸连
问题不在 GROUP BY，而在它前面的 JOIN 已经把行数撑爆了。比如 orders 和 order_items 一对多，再 JOIN customers，不加控制就会按明细行 × 客户行爆炸。
- 对“多”侧表强制收拢粒度：
(SELECT order_id, SUM(amount) AS total_amt FROM order_items GROUP BY order_id) - 对“一”侧表也做前置过滤：
(SELECT id, name FROM customers WHERE status = 'active') - 子查询里漏
GROUP BY或WHERE deleted = 0，结果照样错——这些都得贴着业务逻辑抠
用窗口函数快速验证膨胀程度
不跑全量 SELECT *，加个窗口函数就能看出哪张表在失控拉数据。这招在线上也安全，不锁表、不改逻辑。
- 示例：
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS order_cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id -
ORDER BY order_cnt DESC LIMIT 5，一眼揪出异常高的u.id - 如果出现大量
order_cnt = 0却又有几个超高值，说明右表存在重复user_id或NULL
真正难的不是写出语法正确的 JOIN，而是确认 ON 两侧字段在真实数据中是否具备一一映射能力——类型是否一致、有无隐式转换、索引是否生效、NULL 和重复值是否可控。这些点不挨个验过，光改 SQL 是压不住膨胀的。
