子查询未关联外层字段必然导致笛卡尔积膨胀。必须显式用外键关联、统一字段类型、按关联键聚合、避免无意义order by/limit，并用count(主表id)而非count(*)统计主表行数。
子查询里没写WHERE关联字段，就等于开了一张空白支票
外层表每行都会跟子查询结果全量组合。比如外层 1000 行 × 子查询 200 行 = 20 万行，而你真正想要的可能只有 100 行匹配。这不是“可能出错”，是必然膨胀。
常见错误写法：SELECT a.name, (SELECT b.value FROM b WHERE b.type = 'config') FROM a——子查询没引用 a.id，它就是个静态集合。
- 正确写法必须显式关联：
SELECT a.name, (SELECT b.value FROM b WHERE b.a_id = a.id AND b.type = 'config') FROM a - 如果子查询返回多行（如一个用户有多个 config），
SELECT ... FROM a会报错或只取第一行（取决于数据库），得改用EXISTS或聚合函数 - MySQL 5.7 及更早版本对
IN (subquery)优化差，遇到空结果、NULL 或大结果集容易退化成嵌套循环扫描，建议优先用EXISTS
LEFT JOIN 套子查询后 COUNT(*) 失真，别信它
COUNT(*) 在 JOIN 后统计的是中间结果行数，不是主表逻辑行数。子查询若没控粒度，一行主表可能对应多行子查询结果，COUNT(*) 就会虚高。
典型陷阱：SELECT COUNT(*) FROM orders o LEFT JOIN (SELECT * FROM payments) p ON o.id = p.order_id——如果某订单有 3 笔支付，这单就算 3 行。
- 统计主表数量，始终用
COUNT(o.id)或COUNT(1)，别依赖COUNT(*) - 子查询必须按关联键聚合或去重：
(SELECT order_id, SUM(amount) FROM payments GROUP BY order_id)，否则粒度不对 - 如果子查询要过滤状态（如只取
status = 'success'），必须写进子查询内部，不能留到外层WHERE
子查询字段类型不一致，索引失效，膨胀藏在执行计划里
外表 a.id 是 BIGINT，子查询里 b.a_id 是 VARCHAR，哪怕值看起来一样，MySQL 也会隐式转换，导致无法走索引。执行计划里 type 显示 ALL 或 index，且 rows 远超实际数据量，基本就是这问题。
- 用
EXPLAIN看子查询部分的rows值，对比该表真实行数；如果高出一两个数量级，立刻检查字段类型 - 修复方式只有统一类型，或在子查询中显式
CAST(b.a_id AS BIGINT)（但不如改表结构彻底） - PostgreSQL 对类型不一致更敏感，
Nested Loop节点下actual rows如果异常高，也先查类型和索引
子查询里 GROUP BY 漏了关联字段，照样变笛卡尔积
子查询用于 JOIN 时，如果写了 GROUP BY 却漏掉外层关联键，结果集仍会爆炸。例如：(SELECT SUM(amount) FROM payments GROUP BY status) 返回 N 行，跟主表 JOIN 就是 N × 主表行数。
- 必须按外层能对齐的字段
GROUP BY，通常是外键，比如order_id、user_id - 子查询里别加
ORDER BY或LIMIT——优化器常无法下推，导致全表聚合后再截断 - 需要最新一条记录？用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC)筛，别靠LIMIT 1侥幸
真正难的不是写出语法正确的子查询，而是判断：这个子查询到底该返回多少行？按什么字段对齐？有没有被业务规则悄悄放大？一不留神，AND deleted = 0 漏写，结果就错。
