postgresql中出现nested loop (join filter: true)或mysql中type: all配合using join buffer，基本确认漏写on条件；需逐个检查join后是否紧接含左右表列的等值条件，避免恒真式、逗号语法缺where、主外键缺失、类型不匹配及null干扰。
查执行计划里有没有 Nested Loop (Join Filter: true)
PostgreSQL 中只要看到这个节点，基本等于确认漏写了 ON 条件；MySQL 对应的是 type: ALL 配合 Extra: Using join buffer，尤其多表 JOIN 时某张表出现这组合，别犹豫，立刻翻 SQL 查它前面那个 JOIN 有没有紧跟着有效的 ON 子句。
常见错误现象：COUNT(*) 明显大于左表行数、SUM() 虚高、查询变慢到超时——不是 GROUP BY 写错了，而是 JOIN 已经失控。
- 逐个检查每个
JOIN后是否立刻跟了ON，且至少含一个左表列和一个右表列（如ON o.id = oi.order_id） - 警惕
ON 1=1、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 BY order_cnt DESC LIMIT 5往往一眼揪出问题源头 - 如果结果里出现
order_cnt = 0却又大量非零值，说明右表存在重复user_id或NULL - 这个技巧在线上环境也安全，不改逻辑、不锁表，只加计算
确认 ON 条件里有没有漏掉主外键等值条件
比如写成 LEFT JOIN orders ON orders.status = 'paid'，漏掉 users.id = orders.user_id，结果就是每个用户都和所有 paid 订单配一遍，数据量爆炸；后续加 LIMIT 或聚合时，看似有结果，实则随机丢数据。
- 检查方法：确认
ON中至少有一组明确的主外键等值条件 - 对多表
JOIN，逐个补全关联路径，不要依赖“反正后面WHERE会筛” - 在测试库用小数据集加
SELECT COUNT(*)验证连接结果集大小
注意字段类型、空值、隐式转换导致的“静默失效”
看起来一样，实际不能等值连接：一个表用手机号（带 +86 前缀），另一个用纯数字；一个存的是用户 ID，另一个存的是旧系统编码；或者字段类型不一致（VARCHAR vs INT）导致隐式转换失败。
- 先用
SELECT DISTINCT分别查两边字段的取值分布，确认是否有隐藏空格、大小写、符号差异 - 用
LENGTH()和TRIM()验证长度与空白符 - 对数值型字段，用
CAST(col AS CHAR)转成字符串再比对，避免类型干扰 -
NULL值参与比较会导致条件失效：NULL = 'paid'全为UNKNOWN，不进WHERE真值集合
EXPLAIN 都可能看不出异样。
