JOIN 返回百万行是因为缺少有效关联条件或关联字段存在大量NULL/重复值，导致隐式笛卡尔积；典型表现是结果行数远超理论上限、耗时陡增、内存爆满。
为什么 JOIN 突然返回了百万行？
这不是数据量变大了，而是 JOIN 缺少有效关联条件，或关联字段存在大量 NULL / 重复值，导致数据库执行了隐式笛卡尔积。典型现象是：结果行数远超左右表行数乘积的“理论上限”，或者查询耗时陡增、内存爆满。
ON 条件漏写或写错
最常见原因：手误漏掉 ON 子句，或把 AND 写成 =，或用了错误字段名。MySQL 和 PostgreSQL 在缺少 ON 时会直接报错，但 SQL Server 和旧版 SQLite 可能静默退化为交叉连接。
- 检查执行计划里是否出现
Hash Match (Inner Join)或Nested Loops但Estimated Rows异常高 - 用
EXPLAIN（MySQL/PostgreSQL）或SET SHOWPLAN_ALL ON（SQL Server）确认实际使用的连接类型 - 临时把
JOIN改成LEFT JOIN并加WHERE right_table.id IS NOT NULL，观察行数是否回落——若回落，说明原ON条件未生效
关联字段存在大量 NULL 或重复值
NULL = NULL 永远为 FALSE，所以含 NULL 的字段做 ON 时，这些行会被丢弃；但如果左表某 id 对应右表 1000 条记录，就会放大 1000 倍。
- 运行
SELECT COUNT(*) FROM left_table WHERE join_col IS NULL和SELECT join_col, COUNT(*) FROM right_table GROUP BY join_col HAVING COUNT(*) > 10快速定位脏数据 - 避免用
COALESCE(join_col, -1)粗暴填充NULL——这可能把本不该关联的行强行拉进来 - 如业务允许，优先在
ON中加过滤，例如ON a.id = b.a_id AND b.status = 'active'，而非全量关联后再WHERE
多表 JOIN 顺序与中间结果膨胀
三张表连查时，前两个表先 JOIN 得到 10 万行中间结果，再跟第三张表关联——哪怕第三张表只有 10 行，只要关联键不唯一，也可能翻倍放大。
- 用括号显式控制结合顺序：
(t1 JOIN t2 ON ...) JOIN t3 ON ...，比默认左结合更易推理 - 对中间结果大的表，提前用
WHERE过滤（注意：放在JOIN后的WHERE无法减少连接基数，要放到对应ON或子查询中） - 考虑用
WITH子句物化中间结果并加索引提示（如 PostgreSQL 的MATERIALIZED）
笛卡尔积不是语法错误，而是语义失控。真正难排查的，往往是那个看起来“应该没问题”的 ON 条件——比如字段类型隐式转换导致索引失效，或时间字段没对齐时区，让本该匹配的行全部落空，反而触发了全表扫描式连接。
