根本原因是join顺序和连接条件未约束中间结果集大小，如left join使用无索引或函数化的on字段导致全量组合后过滤，需确保on条件sargable、复合join不漏字段，并通过explain检查type、key、rows等指标定位膨胀点。
为什么加了WHERE条件还是出现笛卡尔积
根本原因不是WHERE写得不够多，而是JOIN顺序和连接条件没约束住中间结果集大小。比如LEFT JOIN后跟一个没索引的ON字段，或ON里用了函数（如UPPER(a.name) = UPPER(b.name)），数据库就无法用索引下推，导致先做全量组合再过滤。
- 检查执行计划里
rows列：如果某次JOIN前的rows是10万，JOIN表有5千行，而rows突然跳到5千万，基本就是笛卡尔积苗头 -
ON条件必须是SARGable的——避免在连接字段上套函数、类型隐式转换（如INT列和VARCHAR字符串比较） - 复合连接时，确保所有
ON子句都参与约束，别漏掉关键字段，例如ON a.id = b.a_id AND a.dt = b.dt漏了dt就可能放大结果
如何用EXPLAIN快速定位JOIN膨胀点
别等查完才看性能，要在写完SQL第一轮就跑EXPLAIN FORMAT=TRADITIONAL（MySQL）或EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）。重点盯三处：
-
type字段：出现ALL或index说明走了全表/全索引扫描，JOIN前没有效过滤 -
key字段为空：表示没走索引，哪怕WHERE写了字段，也可能因OR、NOT IN、函数导致失效 -
rows预估数和实际filtered百分比：如果filtered: 0.1%，说明99.9%的中间行被后续WHERE干掉了——该把这部分条件提前到ON里
哪些JOIN写法会悄悄触发笛卡尔积
不是语法报错才算问题，很多“合法”写法在数据分布不均时等效于笛卡尔积：
-
LEFT JOIN右边表无匹配时补NULL，但如果右边是聚合结果且没加DISTINCT或GROUP BY，一行可能对应多行，放大左表 - 多个
OR条件混在ON里，如ON a.id = b.x OR a.id = b.y，优化器常放弃索引合并，退化为嵌套循环+全扫 - 子查询当JOIN表但没加
LIMIT或WHERE剪枝，尤其在MySQL中，派生表默认不物化，可能反复执行
谓词下推不到JOIN里的典型陷阱
很多人以为WHERE里的条件总能自动“下推”到JOIN过程，其实受方言和优化器版本限制很大：
- MySQL 5.7之前，
WHERE里涉及右表字段的条件，不会下推到LEFT JOIN的右表扫描阶段，导致先全量JOIN再过滤 - PostgreSQL对
INNER JOIN下推友好，但遇到LATERAL或CTE嵌套过深时，可能因统计信息不准放弃下推 - 解决办法很直接：把能缩小右表范围的条件，显式挪进
ON，例如把WHERE b.status = 'active'改成ON ... AND b.status = 'active'
user_id在订单表里出现20万次，那它和用户维度表一JOIN，不管怎么写ON，中间集天然就大。这时候得先想清楚：这真是要JOIN，还是该用EXISTS或聚合后关联？
