确认发散是否真实存在：先查左表COUNT()，再查JOIN后COUNT()，若后者远大于前者（如1万→8万），说明膨胀已发生；再查右表连接键重复SELECT key, COUNT() FROM right_table GROUP BY key HAVING COUNT() > 1；同时确保右表过滤条件写在ON而非WHERE中。
确认发散是否真实存在
别一看到结果行数多就改SQL，先验证是不是真膨胀了。LEFT JOIN后行数翻倍、SUM虚高、COUNT不准，八成是中间结果已爆炸。执行两步检查：COUNT(*)查左表原始行数；再跑完整JOIN查询加COUNT(*)看总数。如果后者远大于前者（比如左表1万行，JOIN后变8万行），说明发散已发生。此时别急着加GROUP BY或DISTINCT——它们只处理最终结果，拦不住中间膨胀，还可能掩盖真正问题。
查右表连接键是否重复
发散的根因几乎总是右表连接字段不唯一。比如用user_id关联用户表和地址表，但地址表里一个user_id存了3条历史地址，LEFT JOIN就会把左表同一用户撑成3行。直接查右表：SELECT user_id, COUNT(*) FROM address GROUP BY user_id HAVING COUNT(*) > 1。有返回就坐实了问题。注意：这不是数据脏，而是业务逻辑没对齐——你要的是“最新地址”还是“全部地址汇总”？选错路径，后面全错。
ON和WHERE位置错误导致隐式过滤
这是线上最高频的逻辑陷阱。LEFT JOIN后在WHERE里写右表条件（如WHERE addr.status = 'active'），等于先全量配对再砍掉NULL行，LEFT退化为INNER，且中间结果早已膨胀。正确做法是把业务过滤塞进ON：LEFT JOIN address addr ON u.id = addr.user_id AND addr.status = 'active'。特别注意：MySQL 5.7+、PostgreSQL支持良好，但某些旧版SQLite或ODBC驱动可能不认AND后的条件，上线前务必实测。临时排查时，可先去掉所有WHERE，只跑SELECT *，看右表字段是否大量为NULL，再逐条加回条件定位哪一行触发截断。
用窗口函数快速定位膨胀源头
不用跑全量聚合，加个COUNT(*) OVER (PARTITION BY ...)就能一眼看出谁在撑开数据。例如查用户订单异常：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_cnt DESC排序，前几条若显示几百上千，而你预期最多几十，那不是数据本身多，是连接逻辑崩了。这个技巧不锁表、不改逻辑，线上环境也安全。如果发现order_cnt = 0和大量非零值并存，说明右表存在NULL或重复user_id，得回头查数据质量。
WHERE误用 + 类型隐式转换，三者叠加会让问题更难定位。最容易被忽略的是类型不一致引发的隐式转换失败——比如一边是VARCHAR手机号带+86，另一边是纯数字INT，数据库尝试转DOUBLE时精度丢失，导致本不该匹配的行被拉进来，还查不出明显报错。 
