漏写 on 或 where 关联字段是笛卡尔积最常见原因：嵌套查询中子查询与外层表无明确关联时，数据库将其视为静态集合，导致全量组合；explain 中 rows 远超实际行数即为连接膨胀标志。
漏写 ON 或 WHERE 关联字段是笛卡尔积最常见原因
嵌套查询里一旦子查询和外层表之间没建立明确关联，数据库就会把子查询结果当成一个“静态集合”，跟外层每一行做全量组合。比如外层 1000 行 × 子查询 500 行 = 50 万行，而你本意可能只想要匹配的 100 行。
关键判断点：EXPLAIN 输出中某张表的 rows 值远超其实际数据量（比如显示 500000，但该表真实只有 1000 行），基本就能确认连接膨胀了。
- 显式 JOIN 必须带
ON，不能只写JOIN table_b就结束 - 老式逗号语法（
FROM a, b）必须在WHERE里补全所有关联，例如a.id = b.a_id和b.status = 'active'都得写进去，缺一不可 - 子查询若含
GROUP BY或聚合，它已不是原始表结构——外层不能再假设用id直接对齐，得用WHERE x IN (SELECT y FROM ...)或改用EXISTS
IN 子查询在 MySQL 中容易隐式触发笛卡尔式扫描
WHERE x IN (SELECT y FROM t) 看起来安全，但在 MySQL 5.7 及更早版本里，当子查询返回空、含 NULL、或外层有多个可匹配字段时，优化器可能放弃半连接（semi-join），退化成嵌套循环+全表扫描，效果等同于手动制造笛卡尔积。
- 优先改用
WHERE EXISTS (SELECT 1 FROM t WHERE t.y = outer.x)，语义清晰且 MySQL 对EXISTS的路径选择更稳定 - 子查询里避免
SELECT *，只查必要字段；如果要去重，显式写SELECT DISTINCT y，否则某些版本会多加一层临时表 - PostgreSQL 对
IN (subquery)优化较好，但 MySQL 在子查询结果超 1000 行时大概率放弃哈希半连接，转走慢路径
LEFT JOIN 套子查询后 COUNT(*) 失真问题
典型错误写法：SELECT COUNT(*) FROM a LEFT JOIN (SELECT * FROM b WHERE cond) c ON a.id = c.a_id。本意是统计 a 表总行数，但若子查询为空，COUNT(*) 仍返回 a 行数；若子查询因去重失败或关联字段不唯一导致重复匹配，COUNT(*) 就会大于 COUNT(a.id)，结果完全失真。
- 统计主表数量，直接用
COUNT(a.id)或COUNT(1)，别依赖COUNT(*)在 JOIN 后的结果 - 子查询若需过滤，尽量提前下推：把
WHERE cond写进子查询内部，而不是留到外层再ON或WHERE - 如果子查询结果需参与多对一匹配，检查
c.a_id是否有索引；没有的话，ON条件可能无法驱动高效查找，间接放大中间结果集
多表嵌套时中间结果膨胀比最终 SQL 更危险
三张表以上嵌套时，问题往往不出在最后一层，而是前两表连接后已经生成巨大中间集，后续再 JOIN 第三张表只是雪上加霜。比如 a JOIN b ON a.id = b.a_id 返回 10 万行，再 JOIN c ON b.c_id = c.id，哪怕 c 只有 100 行，也可能撑爆内存。
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN ANALYZE（PostgreSQL）看每一步的输出行数，定位膨胀源头 - 考虑把高基数过滤条件提前：比如
b.status = 'done'比a.created_at > '2025-01-01'选择性更高，就该先筛b再连a - 实在无法避免大中间集，宁可用多次单表查询 + 应用层组装，也别让数据库扛着 500 万行做嵌套
真正难防的不是语法错误，而是你以为加了条件就安全了，结果子查询本身没约束、字段类型隐式转换、或索引失效，让数据库悄悄退回全量组合。每次改完嵌套查询，EXPLAIN 看一眼 rows 和 type，比测数据更早发现问题。
