应控制子查询嵌套至两层、慎用三层，按where/select/from位置区分语义，优先用非相关子查询或窗口函数替代相关子查询，并通过索引优化关联字段。
SQL 子查询嵌套不是“能用就行”，关键在于什么时候该嵌、嵌几层、怎么写才高效又可读。过度嵌套容易导致性能骤降和逻辑混乱，而合理嵌套则能精准表达复杂业务逻辑——比如“查出每个部门工资最高的员工，且该员工入职时间早于部门平均入职时间”。这类需求单靠 JOIN 或 GROUP BY 很难一步到位，子查询嵌套反而更直观、可控。
一、嵌套层级控制：两层够用，三层慎用
多数业务场景中，两层子查询（即主查询中含一个子查询，该子查询自身再含一个子查询）已足够覆盖需求。三层及以上嵌套不仅可读性急剧下降，还容易触发执行计划退化——数据库优化器可能放弃使用索引，转而全表扫描。
- 推荐结构：主查询 → WHERE/SELECT 中的标量子查询 → FROM 中的派生表（或另一个 WHERE 条件子查询）
- 避免写法：WHERE (SELECT ... WHERE (SELECT ... WHERE (SELECT ...))) 这类纯深度嵌套
- 替代思路：三层逻辑可拆为临时表、CTE 或 JOIN 配合窗口函数。例如统计“城市中薪资高于本城平均、且所在公司规模大于行业均值”的员工，用 CTE 分步计算城市均薪、行业公司规模均值，比三层嵌套清晰得多
二、位置决定语义：WHERE / SELECT / FROM 各有分工
子查询放在不同位置，作用完全不同，选错位置轻则报错，重则结果错误。
-
WHERE 中的子查询：用于条件过滤，必须返回单值（标量）或值列表。如
WHERE salary > (SELECT AVG(salary) FROM employees)；若需多值匹配，用IN或EXISTS -
SELECT 列表中的子查询：必须是标量子查询（返回一行一列），常用于关联聚合结果。如
SELECT name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u -
FROM 中的子查询（派生表）：可返回任意行列结果，必须命名别名。适合预聚合、分页、去重等前置处理。如
SELECT dept, avg_salary FROM (SELECT dept, AVG(salary) AS avg_salary FROM employees GROUP BY dept) t WHERE avg_salary > 10000
三、性能关键：相关子查询 vs 非相关子查询
是否“相关”取决于子查询是否引用外部查询字段。非相关子查询只执行一次，效率高；相关子查询对主查询每一行都执行一次，极易成为性能瓶颈。
-
识别相关子查询：看子查询里是否有来自外部表的列，如
WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept = e1.dept)中的e1.dept -
优化手段：
- 用 JOIN + GROUP BY 替代相关标量子查询（如部门平均薪资）
- 用窗口函数替代部分相关子查询，如
AVG(salary) OVER (PARTITION BY dept)直接在主查询中计算 - 必要时加索引：相关子查询的关联字段（如 dept）务必建索引
四、实战案例：找出“薪资高于本部门平均、且绩效评分在部门前3”的员工
这是一个典型需嵌套+排序+限制的场景，直接用子查询组合最自然：
SELECT e1.name, e1.salary, e1.score
FROM employees e1
WHERE e1.salary > (
-- 第一层：部门平均薪资
SELECT AVG(e2.salary)
FROM employees e2
WHERE e2.dept = e1.dept
)
AND e1.score IN (
-- 第二层：取本部门绩效前3名（用相关子查询+LIMIT需注意兼容性，此处用窗口更稳）
SELECT score FROM (
SELECT score,
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY score DESC) AS rn
FROM employees e3
WHERE e3.dept = e1.dept
) t
WHERE t.rn <p>更优写法（推荐）：用 CTE 预计算部门均薪和排名，再 JOIN 过滤，逻辑分层、易调试、性能更稳。</p> 
