子查询应优先用JOIN替代IN，存在性判断选EXISTS，相关子查询需改LEFT JOIN+GROUP BY，FROM子句子查询必须加别名和字段前缀。
子查询写在 WHERE 里，但别直接套用 IN 处理大表
很多业务场景要查“属于某类用户的所有订单”，第一反应是 SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE type = 'vip')。这在小数据量下没问题，但一旦 users 表超百万行，IN 子查询可能被 MySQL/PostgreSQL 优化成临时表+嵌套循环，性能断崖下跌。
- 优先改用
JOIN：更可控、索引更容易命中，特别是user_id和users.id都有索引时 - 如果必须用
IN，确保子查询结果集很小（比如固定枚举 ID 列表），否则加LIMIT 1000并监控执行计划 - PostgreSQL 用户注意：
IN (SELECT ...)在 12+ 版本默认走哈希连接，但若子查询含ORDER BY或LIMIT，可能退化为 Nested Loop
EXISTS 比 IN 更适合存在性判断
当你要查“至少下过一单的 VIP 用户”，写成 SELECT * FROM users u WHERE u.type = 'vip' AND u.id IN (SELECT user_id FROM orders) 是错的——IN 会去重、会空值敏感；而 EXISTS 只关心是否存在匹配行，语义准确且通常更快。
-
EXISTS不受NULL干扰：IN遇到子查询返回NULL时整行判为UNKNOWN，结果意外丢失 - 子查询里必须关联外层表，比如
SELECT 1 FROM orders o WHERE o.user_id = u.id，否则变成恒真/恒假 - SQL Server 中
EXISTS的执行计划常显示为 “Nested Loops + Index Seek”，比IN的 “Hash Match” 更稳定
相关子查询慎用于聚合场景，避免 N+1 查询陷阱
写 SELECT id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u 看似清晰，实际是典型的相关子查询：对 users 表每行都执行一次子查询。10 万用户 = 10 万次独立查询，IO 和连接开销爆炸。
- 一律改用
LEFT JOIN + GROUP BY：先聚合再关联，数据库能一次性扫表并哈希分组 - 如果业务强依赖单行子查询（如计算每个用户的最新订单时间），确认
orders(user_id, created_at)有联合索引，否则MAX(created_at)子查询会全表扫描 - MySQL 8.0+ 支持窗口函数，类似需求可改用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，效率高且逻辑集中
子查询当表用时，别漏掉别名和字段限定
把子查询放 FROM 后当临时表用，比如 SELECT t.total FROM (SELECT user_id, SUM(amount) total FROM orders GROUP BY user_id) t WHERE t.total > 1000，看着没问题，但实际容易栽在两个地方：
- 所有子查询都必须带别名（
t），否则 PostgreSQL 报错，MySQL 5.7+ 也要求，不是可选项 - 外层引用字段必须加别名前缀（
t.total），尤其当子查询字段名和外层表重复时，不加会导致歧义或报错Column 'total' in field list is ambiguous - 子查询里不能用外层表字段（除非是相关子查询），比如
FROM (SELECT * FROM orders WHERE user_id = u.id)在非相关上下文中语法非法
复杂业务建模真正卡住人的，往往不是逻辑多绕，而是子查询层级深了之后，字段作用域和执行时机悄悄变了——多看一眼执行计划里的 DEPENDENT SUBQUERY 标记，比硬背规则管用。
