应优先用EXISTS替代IN处理多条件动态筛选，因EXISTS天然忽略NULL且支持子查询内AND/OR组合；SELECT中标量子查询须严格单行单列；FROM中派生表必须显式别名；相关子查询性能差时应改写为JOIN。
WHERE 中嵌套子查询做多条件判断，别直接堆 IN
多条件动态筛选最常发生在 WHERE 子句里，比如“查有订单且最近登录过、且所在城市在白名单中的用户”。这时候容易下意识写成：WHERE user_id IN (SELECT id FROM users WHERE city IN ('Beijing', 'Shanghai')) AND last_login > '2025-01-01'。但问题在于：一旦子查询里 city 字段含 NULL，整个 IN 判断就失效，结果为空——不报错，也不提示。
更稳妥的做法是拆开逻辑，用 EXISTS 替代 IN，并把多个条件压进子查询内部：
-
EXISTS天然忽略NULL，只关心“有没有匹配行” - 子查询中可自由组合
AND/OR，比如u.city IN (...) AND u.last_login > ... - 数据库通常能提前终止，比
IN全量收集成员再比对更快
示例：SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active' AND u.city IN ('Beijing', 'Shanghai') AND u.last_login > '2025-01-01')
SELECT 列中用标量子查询拼接动态字段，必须单行单列
当你需要为每行主表数据动态算出一个值（比如“该用户最近一笔订单金额”或“所属部门平均薪资”），就得把子查询放在 SELECT 列表里。但这里卡点极严：子查询必须返回且仅返回一个值，否则直接报错 ERROR 1242 (21000): Subquery returns more than 1 row。
常见踩坑点：
- 漏写
WHERE关联条件，导致子查询扫全表返回多行 - 用了
GROUP BY却没加聚合函数，或聚合后仍可能多行（如没去重） - 子查询里引用了外层字段但没加索引，10 万行主表 = 执行 10 万次子查询
正确写法示例：SELECT name, (SELECT amount FROM orders o2 WHERE o2.user_id = u.id ORDER BY created_at DESC LIMIT 1) AS last_order_amount FROM users u。注意用了 LIMIT 1 保单行，且 (user_id, created_at) 建复合索引能避免排序扫描。
FROM 中用派生表预聚合，别名是硬性语法要求
当多条件筛选依赖中间聚合结果（比如“查平均订单额 > 500 且近 30 天下单次数 ≥ 3 的用户”），直接在 WHERE 里写两层子查询会难读难调。更清晰的路径是：先在 FROM 里用子查询生成临时汇总表，再对外层加条件。
但 MySQL/PostgreSQL 都强制要求这个子查询必须带别名，否则报错 ERROR 1248 (42000): Every derived table must have its own alias。
- 别名必须显式写出，
AS temp或空格隔开的temp都合法，但(SELECT ...)不行 - 外部查询中所有列都得通过别名引用，比如
temp.avg_amount，不能直接写avg_amount - 如果子查询里用了
ORDER BY或LIMIT，记得确认是否影响聚合逻辑（例如LIMIT在聚合前截断会导致结果偏差）
示例：SELECT u.name, t.avg_amount FROM users u JOIN (SELECT user_id, AVG(amount) AS avg_amount, COUNT(*) AS order_cnt FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY user_id HAVING AVG(amount) > 500 AND COUNT(*) >= 3) AS t ON u.id = t.user_id
相关子查询性能差时，优先 EXPLAIN 再改写为 JOIN
相关子查询（即子查询里引用了外层表字段）写起来顺手，但执行代价常被低估。比如 SELECT *, (SELECT MAX(created_at) FROM orders o2 WHERE o2.user_id = u.id) AS last_order_time FROM users u，如果 users 表有 10 万行，数据库真会跑 10 万次子查询 —— 即使加了索引，I/O 和解析开销也很大。
实际优化步骤很务实：
- 先用
EXPLAIN看执行计划，确认子查询是否走了索引、是否标记为DEPENDENT SUBQUERY - 若发现慢，立刻尝试等价改写为
LEFT JOIN + GROUP BY，让数据库一次扫描完成聚合 - JOIN 版本更容易加覆盖索引（如
(user_id, created_at)），而相关子查询很难利用复合索引的第二列
改写示例：SELECT u.*, COALESCE(g.last_time, '1970-01-01') AS last_order_time FROM users u LEFT JOIN (SELECT user_id, MAX(created_at) AS last_time FROM orders GROUP BY user_id) g ON u.id = g.user_id
真正难的不是写出子查询，而是判断它该不该出现在那个位置：WHERE 里要不要拆条件，SELECT 里敢不敢放，FROM 里值不值得建临时表。每个选择背后，都是索引、执行计划和数据分布的现实约束。
