笛卡尔积本质是逻辑失控而非语法错误，主因包括漏写ON、恒真条件、USING字段不一致、子查询未关联、多明细表直接JOIN等，需通过执行计划、实际行数和过滤位置精准定位。
只要结果行数远超主表行数，基本就是笛卡尔积已发生——不是语法报错，而是逻辑失控。
检查每个 JOIN 后是否真有有效 ON 条件
漏写 ON 是最直接的触发点，但更常见的是写了却等于没写：
-
ON u.id = u.id或ON 1=1这类恒真条件，数据库不报错，但连接完全失效 -
USING (name)要求两表字段名、类型、值域都一致，否则匹配松散，name重复率高时极易放大行数 - 子查询作右表时，仍需
ON关联，不能依赖子查询内部WHERE：比如(SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) p必须用ON o.id = p.order_id，不能ON 1=1
一对多表同时 JOIN 主表时，别让明细互相组合
主表 1 行 + 明细表 A 3 行 + 明细表 B 5 行 → 直接三表 LEFT JOIN 会出 15 行，这不是错误，是数据库在“老实干活”。
- 若只需汇总值（如总金额、订单数），优先用子查询先聚合：
(SELECT main_id, SUM(amount) AS total FROM detail_a GROUP BY main_id)再JOIN，确保每main_id只有一行 - 若需保留明细字段（如最新商品名、最大数量），改用窗口函数去重：
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC)筛出单条再关联 - 避免在
SELECT中对多表字段直接DISTINCT，这是先膨胀再收缩，代价更高
执行计划里看 “Join Filter: true” 或 “Using join buffer”
这些不是警告，是确诊信号：
- PostgreSQL 执行计划中出现
Nested Loop (Join Filter: true)，说明优化器没找到可用索引或有效等值条件，被迫全量扫描右表 - MySQL 出现
type: ALL+Extra: Using join buffer，尤其多表 JOIN 中某张表单独出现该组合，大概率是它前面那个JOIN缺失约束 - 别信
rows估算值，重点看actual rows（PG）或rows_examined_per_scan（MySQL）；若某表实际扫描上万行而预估仅 1 行，问题就在这
WHERE 和 ON 的位置决定中间集大小
过滤条件放错地方，会让数据库先生成爆炸级中间结果，再砍掉——性能比正确写法差一个数量级。
-
LEFT JOIN order_items i ON o.id = i.order_id AND i.status = 'shipped'：未发货订单仍保留，且中间集最小 -
LEFT JOIN ... ON o.id = i.order_id WHERE i.status = 'shipped'：先拉出所有明细（含未发货），再过滤，NULL 行被干掉，语义变味且中间集巨大 - 涉及右表的过滤，只要不想丢左表数据，一律写进
ON；只有纯左表筛选（如o.created_at > '2026-01-01'）才放WHERE
真正难处理的不是漏写 ON，而是关联字段本身存在大量重复值或 NULL —— 这种问题不会在语法层暴露，只能靠 GROUP BY + HAVING COUNT(*) > 1 主动查脏数据。一旦发现，得先清洗或加业务规则兜底，而不是靠 SQL 技巧硬扛。
