最直接信号是 PostgreSQL 执行计划中出现 Nested Loop (Join Filter: true) 或 MySQL 中 type: ALL 配合 Extra: Using join buffer，表明可能漏写 ON 条件导致隐式笛卡尔积。
查执行计划里有没有 Nested Loop (Join Filter: true)
这是 PostgreSQL 中最直接的信号：只要看到 Nested Loop 节点下跟着 Join Filter: true 或 Rows Removed by Join Filter: 0，基本就是漏写了 ON 条件，数据库被迫对左表每行都扫描右表全量——本质是隐式 CROSS JOIN。
MySQL 里对应的是 type: ALL 配合 Extra: Using join buffer，尤其当多表 JOIN 时某张表出现这个组合，别犹豫，先翻 SQL 看它前面那个 JOIN 后面有没有紧跟着有效的 ON 子句。
- 检查每个
JOIN关键字后是否立刻跟了ON，且该子句中至少含一个左表列和一个右表列（比如ON u.id = o.user_id，而不是ON u.id = u.id） - 警惕别名污染：
users u JOIN orders o ON u.id = u.id这种自等式不会报错，但会让连接失效 - 如果用了逗号分隔表（
FROM a, b），必须确保WHERE里有明确的关联条件，否则就是裸笛卡尔积
用 COUNT(*) OVER (PARTITION BY ...) 快速验证膨胀程度
不跑全量 SELECT *，先加个窗口函数看单条主表记录到底拉出了多少从表行。比如查用户订单数异常，就写：
SELECT u.id, u.name,
COUNT(*) OVER (PARTITION BY u.id) AS order_cnt
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;
如果某个 u.id 对应的 order_cnt 动辄几百上千，而你预期最多几十，那不是数据本身多，而是连接逻辑失控了。
- 这个技巧在线上环境也安全，不改逻辑、不锁表，只加计算
- 结果里如果出现
order_cnt = 0却又大量非零值，说明右表存在重复user_id或 NULL 值 - 别只看平均值——关注最大值和分布，
ORDER BY order_cnt DESC LIMIT 5往往一眼揪出问题源头
确认关联字段是否存在重复值或 NULL
即使 ON 写对了，orders.order_id 在订单表里重复两次、或 order_items.order_id 有 NULL，都会让 JOIN 结果成倍膨胀。这不是语法错误，是数据质量问题。
- 先分别查重复：
SELECT order_id, COUNT(*) FROM orders GROUP BY order_id HAVING COUNT(*) > 1 - 再查 NULL：
SELECT COUNT(*) FROM order_items WHERE order_id IS NULL - 类型不一致也会触发隐式转换，比如
t1.id是BIGINT，t2.t1_id是VARCHAR，索引会失效，优化器可能放弃嵌套循环而选哈希连接，中间结果集照样爆炸
别把过滤条件错塞进 ON 而不是 WHERE
在 LEFT JOIN 中，ON 里写 AND status = 'paid' 和在 WHERE 里写，语义完全不同。前者会让右表不满足条件的行以 NULL 补齐，后者是先连接再过滤——但如果你本意是过滤右表，却放错了位置，就会导致左表所有行都被保留，右表 NULL 行堆满结果集，视觉上像笛卡尔积。
- 原则：关联逻辑放
ON，业务筛选放WHERE - 验证方法：把
LEFT JOIN临时换成INNER JOIN执行，如果行数依然爆炸，说明问题出在关联条件本身，不是WHERE放错 - 常见陷阱：
LEFT JOIN order_items ON o.order_id = i.order_id AND i.deleted = 0—— 这会让已删除的明细不参与连接，但如果你后续还要统计“总明细数”，就得另起子查询
ON，而是找到之后发现字段上有重复值、NULL、类型不匹配，或者压根没意识到 ON 里混进了业务条件。这些细节不逐条验证，光补个 ON 只能治标。 
