笛卡尔积一定发生于JOIN缺失或无效ON条件时；须确保每个JOIN后紧跟有效ON子句，LEFT JOIN过滤条件必须放ON内，子查询JOIN需真实关联，多表连接要检查每对相邻表的业务ON条件。
只要JOIN没写ON，或者ON条件无效，笛卡尔积就不是“可能”，而是“一定发生”——尤其当表行数上万时，结果集会瞬间飙到亿级，查询直接卡死或OOM。
每个JOIN后面必须紧跟有效ON子句
MySQL 8.0+ 和 PostgreSQL 会直接报 ERROR 1064 或语法错误，但 SQLite、旧版 MySQL（5.6 及更早）会静默执行全量交叉连接。别指望数据库替你猜关联逻辑。
- ❌ 错误写法：
SELECT * FROM orders JOIN customers;（缺ON） - ✅ 正确写法：
SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id; - ⚠️
USING (customer_id)可以替代ON，但要求两表字段名完全一致、类型兼容，不是“省事借口” - ⚠️
ON 1=1或ON a.name = b.name（姓名重复率高）等同于没限制，照样爆炸
LEFT JOIN的右表过滤条件必须写进ON，不能放WHERE
WHERE 是连接完成后再筛选，而 ON 控制连接过程本身。把右表条件塞进 WHERE，等于先生成全部 NULL 匹配行，再一刀砍掉——性能差、逻辑错、还浪费资源。
- ❌ 错误：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 所有无客户匹配或状态非 active 的订单全丢，实际退化为INNER JOIN - ✅ 正确：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 左表行数不变，只拉活跃客户 - ? 如果业务要“所有订单 + VIP用户信息”，
WHERE里绝不能出现c.level这类右表字段
子查询作表时，仍需真实ON关联且控粒度
子查询一旦出现在 FROM 或 JOIN 右侧，它就是一张临时表，和外层之间仍需业务意义明确的 ON 条件。漏掉或写成 ON 1=1，等于裸连大表。
- ❌ 危险：
LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) b ON 1=1→ 等效于没限制 - ✅ 安全：
LEFT JOIN (SELECT order_id, SUM(amount) AS total FROM payments GROUP BY order_id) b ON a.id = b.order_id - ⚠️ 若子查询不含外层可关联的字段（如没
order_id），就不能直接JOIN，应改用标量子查询或EXISTS - ? 一对多场景下，优先在子查询里聚合；要最新一条而非全部明细，用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC)筛
多表JOIN必须检查每对相邻表是否都有业务ON条件
不能只确保首尾两张表有关联，中间每一对都得有真实业务逻辑的 ON。跳过中间实体强行连接，数据库只能暴力匹配，中间表形同虚设。
- ❌ 错误链路：
orders JOIN products ON orders.id = products.id→ 没这业务逻辑，order_items被绕过 - ✅ 正确链路：
orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON order_items.product_id = products.id - ? 验证方法：对每个
JOIN后加LIMIT 5查看行数是否合理；若某步后突增数十倍，大概率断链了 - ? 字段类型不一致（如
BIGINTvsVARCHAR）会导致索引失效，间接触发哈希连接+全量膨胀，务必用SHOW CREATE TABLE对比
真正危险的不是语法报错，而是那些“看起来能跑通”的SQL：字段名对得上、ON 写了、WHERE 也加了——但 ON 里用了函数、类型隐式转换、漏了复合主键字段，或者子查询没去重。这些都会让优化器放弃索引下推，在内存里默默组合出百万行中间集。
