sql子查询用于拆解复杂逻辑，适用于“基于结果再筛选”或“动态计算参照值”，分WHERE标量子查询、FROM派生表、select标量子查询三类，需据场景选写法并避性能陷阱。
SQL子查询不是“套娃游戏”，而是把复杂逻辑拆解成可验证的小步骤。用对了，代码更清晰；用错了，性能直接掉坑里。关键在分清场景、选对写法、避开常见陷阱。
什么时候该用子查询？
子查询适合解决“基于结果再筛选”或“动态计算参照值”的问题，比如：
- 查出“销售额高于部门平均值的员工”——平均值得先算出来，再比对
- 找出“没下过单的客户”——需要从订单表反向排除客户ID
- 给每条记录附加一个聚合值，如“当前商品价格占品类均价的比例”
如果只是简单关联两表，优先考虑 JOIN；子查询的价值在于表达“中间结果依赖”。
三类常用子查询写法与优化要点
1. WHERE 中的标量子查询（返回单值）
适合做条件过滤，但必须确保只返回一行一列，否则报错。
✅ 推荐写法：用 EXISTS 替代 IN 处理空值和NULL安全问题
❌ 避免写法：WHERE id IN (SELECT id FROM large_table WHERE …) —— 子查询结果大时效率低，且NULL会让整个条件为UNKNOWN
2. FROM 中的派生表（子查询当临时表）
把子查询结果当一张表来 JOIN 或筛选，逻辑清晰、可控性强。
✅ 推荐写法：给子查询加别名，外层只引用需要字段，避免SELECT *
✅ 小技巧：子查询里提前加 LIMIT 或 WHERE 过滤，减少中间数据量
3. SELECT 列表中的标量子查询
常用于展示型报表，比如每行附带“所在组最大薪资”。
⚠️ 注意：该写法会为每一行执行一次子查询，数据量大时很慢
✅ 优化思路：改用窗口函数（如 MAX() OVER(PARTITION BY …)）替代，性能提升明显
性能避坑指南
子查询慢，往往不是语法错，而是执行计划不合理：
- 检查子查询是否走了索引——特别是 WHERE 和 JOIN 条件涉及的字段
- 避免在子查询中用函数包裹字段（如 WHERE YEAR(create_time) = 2024），会导致索引失效
- 嵌套过深（三层以上）时，考虑拆成临时表或CTE，提升可读性与优化器判断能力
- 用 EXPLaiN 分析执行计划，重点关注“type”是否为 ALL（全表扫描）、“rows”是否远超预期
基本上就这些。子查询不是银弹，但掌握它怎么“分步思考”、何时“换种写法”，能让SQL既准确又扛得住数据增长。