笛卡尔积必然发生于JOIN缺失、写错或隐式失效时；须逐行检查每个JOIN后紧接有效ON条件，禁用ON 1=1等伪条件，LEFT JOIN过滤必须放ON内，多表连接前需用子查询聚合控量，并用窗口函数验证膨胀。
笛卡尔积不是“可能出错”，而是只要JOIN条件缺失、写错或隐式失效，它就一定发生——而且往往在你看到结果前，数据库已经把内存和IO耗光了。
检查每个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，结果照样错——这些都得贴着业务逻辑抠
验证膨胀程度：用COUNT(*) OVER(PARTITION BY)快速定位
不跑全量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又夹杂几百上千的值，说明orders.user_id有NULL或重复
真正难的不是写出子查询或挪条件，而是判断哪张表该聚合、按什么字段聚合、是否要加时间范围或状态过滤——这些都得贴着业务主键语义和数据质量现状来定。一个AND deleted = 0漏了，整个结果就不可信。
