笛卡尔积是查询逻辑失控的信号，表现为结果行数远超预期；查执行计划中Nested Loop（Join Filter: true）或MySQL的type: ALL+Using join buffer可确认；需检查ON条件有效性、避免OR拼接、合理放置过滤条件、用EXISTS替代LEFT JOIN判断存在性、先聚合再JOIN。
笛卡尔积不是语法错误，而是查询逻辑失控的信号——只要结果行数远超预期（比如主表100行、子表各5行，却返回2000+行），基本可以断定已发生隐式笛卡尔积。
查执行计划里有没有 Nested Loop (Join Filter: true)
这是 PostgreSQL 最直接的线索：只要看到 Nested Loop 节点下跟着 Join Filter: true 或 Rows Removed by Join Filter: 0，说明优化器没找到有效关联条件，被迫对左表每行都扫描右表全量，本质就是隐式 CROSS JOIN。
- MySQL 对应的是
type: ALL配合Extra: Using join buffer，尤其多表 JOIN 时某张表出现这个组合，先翻 SQL 看它前面那个JOIN后有没有紧跟着有效的ON子句 - 别信
EXPLAIN里的rows估算值，重点看actual rows（PostgreSQL）或rows_examined_per_scan（MySQL），如果某张表实际返回上万行而预估只有1行，基本坐实问题出在这张表 - 临时加
LIMIT 10快速验证：如果SELECT u.id, COUNT(*) OVER (PARTITION BY u.id)里某个u.id对应几百上千行，就不是数据多，是连接逻辑崩了
检查每个 ON 子句是否真能约束匹配
有 ON 不等于安全。常见失效场景包括：
-
ON u.id = u.id这类自等式不会报错，但让连接完全失效；ON 1=1或漏写ON直接触发裸笛卡尔积 - 多条件用
OR拼接（如ON a.code = b.code OR a.name = b.name）极易引发意外匹配，优先用AND，OR必须加括号并评估索引是否可用 - 把过滤条件错放在
ON里：比如LEFT JOIN order_items i ON o.id = i.order_id AND i.status = 'shipped'，会导致未发货订单仍保留，但后续若再在WHERE里写i.amount > 0，就会把这部分 NULL 行全干掉，语义混乱 - 关联字段存在大量
NULL或重复值：即使ON写对了，SELECT order_id, COUNT(*) FROM order_items GROUP BY order_id HAVING COUNT(*) > 1查出重复，就说明单个主键会拉出多行明细，叠加其他子表必然放大
用 EXISTS 替代 LEFT JOIN 判断存在性
当只需要确认“主表某条记录在从表是否存在对应项”时，LEFT JOIN + WHERE 右表字段 IS NOT NULL 是典型陷阱：它会先完成全量连接再过滤，中间结果集可能爆炸。
- 差的写法：
SELECT o.* FROM orders o LEFT JOIN order_items i ON o.order_id = i.order_id WHERE i.order_id IS NOT NULL - 推荐写法：
SELECT o.* FROM orders o WHERE EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.order_id) -
EXISTS是半连接，找到第一个匹配即停，不生成中间结果集；但如果后续还要取i的具体字段（如商品名、数量），就得回到JOIN，此时必须确保order_items上有(order_id)或(order_id, item_id)的有效索引
先聚合再 JOIN，而不是 JOIN 后聚合
多个一对多子表同时关联主表时，直接 JOIN 再 GROUP BY 会让所有明细行一次性加载进内存，远超必要。
- 低效方式（明细全拉）：
SELECT c.name, SUM(i.amount), MAX(o.create_time) FROM customers c JOIN orders o ON c.id = o.cust_id JOIN order_items i ON o.id = i.order_id GROUP BY c.id, c.name - 优化方式（先收窄）：
SELECT c.name, a.total_amount, b.max_time FROM customers c LEFT JOIN (SELECT cust_id, SUM(amount) AS total_amount FROM order_items i JOIN orders o ON i.order_id = o.id GROUP BY cust_id) a ON c.id = a.cust_id LEFT JOIN (SELECT cust_id, MAX(create_time) AS max_time FROM orders GROUP BY cust_id) b ON c.id = b.cust_id - 关键点在于：聚合子查询按主表主键分组，输出行数严格等于主表行数，彻底切断子表间的交叉组合
真正难的不是写出不报错的 SQL，而是理解每一行结果背后的业务含义。当发现 COUNT(*) 和 COUNT(DISTINCT user_id) 差距巨大时，别急着调优执行计划，先问一句：这些重复行，到底是数据本身冗余，还是我写的关联逻辑根本没表达清楚“一个用户对应一个订单”的业务约束？
