笛卡尔积主因是JOIN条件缺失或错误，如ON子句遗漏、误用WHERE、OR未加括号、关联列缺乏唯一性或存在NULL，需通过EXPLAIN、COUNT+GROUP BY、外键检查及LIMIT验证定位。
检查JOIN条件是否缺失或错误
笛卡尔积最常见原因是ON子句写错，比如漏掉关联条件、用了OR拼接多个条件但没加括号、或者误用WHERE代替ON。一旦JOIN没有有效限制行匹配逻辑，数据库就会对左表每行都匹配右表所有行。
-
LEFT JOIN t2 ON t1.id = t2.t1_id写成LEFT JOIN t2 ON 1=1或直接省略ON，必然全量交叉 - 多条件JOIN时，
ON t1.a = t2.a OR t1.b = t2.b容易引发意外匹配，应优先用AND，OR需配合括号和索引评估 - 把过滤条件写在WHERE里却忘了它会“退化”LEFT JOIN为INNER JOIN，例如
LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'active'实际等效于INNER JOIN
验证关联列是否具备函数依赖或唯一性
即使JOIN条件语法正确，若关联列不具备区分度（如t2.t1_id存在大量NULL或重复值），仍可能产生远超预期的行数。关键不是“有没有ON”，而是“每条左表记录能对应几条右表记录”。
- 用
COUNT(*)+GROUP BY快速探查：SELECT t1_id, COUNT(*) FROM t2 GROUP BY t1_id ORDER BY COUNT(*) DESC LIMIT 5;
- 检查外键约束是否存在：
SELECT constraint_name FROM information_schema.key_column_usage WHERE table_name = 't2' AND column_name = 't1_id';，没有约束不等于不能JOIN，但意味着你得自己确认业务语义 - 注意NULL值：
t2.t1_id IS NULL的记录在JOIN中会被整体丢弃（除非是RIGHT/ FULL OUTER），但若大量NULL集中在某几条t1.id上，可能掩盖基数失衡问题
用EXPLAIN看实际执行计划中的rows估算
语法没问题、数据分布也看似合理？别信直觉。MySQL/PostgreSQL的EXPLAIN输出里的rows列（或PostgreSQL的Rows Removed by Filter）才是真实水位线。它反映优化器预估的中间结果集大小，比COUNT(*)更贴近JOIN实际开销。
- MySQL中重点关注
type列：出现ALL或index且rows值巨大，说明没走索引，关联列可能未建索引或类型不一致（如INT vs VARCHAR） - PostgreSQL中留意
Nested Loop节点下的actual rows，如果远大于左表行数，基本坐实笛卡尔积已发生 - 类型隐式转换会导致索引失效：比如
t1.id是BIGINT，而t2.t1_id是VARCHAR，即使值相同，JOIN也会全表扫描
临时加LIMIT或分页验证数据膨胀程度
线上不敢直接跑全量？用LIMIT快速定位问题规模。这不是修复手段，而是判断严重性的第一反应。
- 在原始JOIN语句末尾加
LIMIT 100，观察返回行数是否远大于左表样本量（比如左表取10行，结果返回800行 → 平均每行匹配80条） - 对比带与不带JOIN的COUNT：
SELECT COUNT(*) FROM t1vsSELECT COUNT(*) FROM t1 JOIN t2 ON t1.id = t2.t1_id，倍数关系一目了然 - 慎用
DISTINCT治标不治本：它掩盖重复，但无法降低JOIN过程中的内存/CPU消耗，查询仍可能OOM或超时
