漏掉任何一个on条件，查询必然爆炸为笛卡尔积；每个join后必须显式写有效on子句，using要求字段名与类型完全一致，left join的右表过滤须置于on而非where，子查询作表仍需业务关联，explain和窗口函数可快速验证膨胀。
漏掉任何一个 ON 条件，查询就不是“可能出错”，而是必然爆炸——中间结果集会直接变成行数相乘，内存和 I/O 在你看到第一行结果前就已耗尽。
每个 JOIN 后必须紧跟着有效的 ON 子句
显式 JOIN（如 LEFT JOIN、INNER JOIN）不会自动推断关联逻辑。不写 ON，MySQL 8.0+ 直接报 ERROR 1064；旧版或 ORM 生成的 SQL 可能静默退化为 CROSS JOIN，结果就是笛卡尔积。
-
SELECT * FROM orders LEFT JOIN customers;→ 错误：缺ON，等效于CROSS JOIN -
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id;→ 正确 - 用
USING (customer_id)可以替代ON，但要求两表字段名完全一致且类型兼容，不是“省条件”的捷径 - 老式逗号语法
FROM a, b必须靠WHERE补关联，漏一个字段（如a.id = b.a_id）等于没写
LEFT JOIN 的右表过滤必须写进 ON，不能放 WHERE
WHERE 是连接完成后再过滤，ON 才控制连接过程本身。把右表条件放在 WHERE 里，会让原本该保留的左表空匹配行被剔除，等效于 INNER JOIN，还白跑一遍全量配对。
- 错误：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 所有无匹配或状态非 active 的订单都被丢掉 - 正确：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 只拉活跃客户，左表行数不变 - 如果业务要求保留全部订单，又只取 VIP 用户信息，
WHERE中绝不能出现c.level这类右表字段
子查询作表时仍需明确关联，且必须控粒度
子查询一旦出现在 FROM 或 JOIN 右侧，它就变成一张“临时表”，和外层表之间依然需要真实业务意义的 ON 条件。更危险的是：子查询若未聚合或去重，会把明细行原样摊开再连。
- 危险：
LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) b ON 1=1→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 - 一对多关系下，优先在子查询里先聚合；需要最新一条而非全部明细，用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC)筛 - 子查询里漏
GROUP BY、漏WHERE deleted = 0，结果照样错——这些都得贴着业务逻辑抠
用 EXPLAIN 和窗口函数快速验证是否已膨胀
别等全量查询卡死才反应过来。用执行计划和轻量级统计，能在秒级定位哪一步开始失控。
-
EXPLAIN看type列：出现ALL或index且rows远大于表实际行数，大概率是字段类型不一致或缺索引 - PostgreSQL 看
Nested Loop节点下的actual rows，比左表行数高一两个数量级，八成是类型不匹配 - 加窗口函数验证：
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 -
LIMIT 100不是用来“先看看”，而是为了确认问题规模：如果它都卡住或返回重复主键，说明中间结果早已失控
真正难的不是写出带 ON 的语句，而是判断每一对相邻表之间是否存在真实业务意义上的关联链——跳过中间实体强行连接，数据库只能暴力匹配，而这种错误往往在数据量变大后才暴露。
