SQL子查询优化核心是：优先用JOIN替代WHERE/SELECT中的非相关或相关子查询，用EXISTS替代IN处理存在性判断，复杂子查询改用CTE或临时表固化，慎用SELECT中逐行执行的标量子查询。
子查询在SQL中很常见，但写法不当容易拖慢性能。核心思路是：能用连接替代的尽量改写为JOIN，避免在WHERE或SELECT中嵌套非相关子查询，尤其要警惕在大表上执行多次独立子查询。
用JOIN替代WHERE中的相关子查询
当子查询依赖外层表字段（即相关子查询），且只返回单个值时，通常可转为LEFT JOIN + 聚合或窗口函数。例如：
低效写法：
SELECT name, (SELECT AVG(salary) FROM emp e2 WHERE e2.dept_id = e1.dept_id) avg_dept_salary FROM emp e1;优化后：
SELECT e1.name, dept_avg.avg_salary FROM emp e1 LEFT JOIN (SELECT dept_id, AVG(salary) avg_salary FROM emp GROUP BY dept_id) dept_avg ON e1.dept_id = dept_avg.dept_id;说明：原写法对e1每行都执行一次子查询；改写后仅扫描emp两次，通过哈希连接快速匹配。
用EXISTS替代IN处理存在性判断
当子查询仅用于判断“是否存在”，优先用EXISTS而非IN，尤其子查询结果可能含NULL时，IN会意外过滤掉整行。
- IN在子查询返回NULL时整体判定为UNKNOWN，导致主查询不返回该行
- EXISTS只关心是否查到记录，不受NULL影响
- 多数数据库对EXISTS有专门优化，可能提前终止扫描
示例：查有员工的部门
SELECT * FROM dept d WHERE EXISTS (SELECT 1 FROM emp e WHERE e.dept_id = d.id);拆分复杂子查询，用临时表或CTE固化中间结果
若子查询逻辑复杂、被多次引用，或涉及多表聚合/过滤，直接内联会导致重复计算。可先用CTE或临时表预计算。
适用场景：
- 同一子查询在多个地方出现（如SELECT列表和HAVING条件）
- 子查询本身已含GROUP BY、DISTINCT或窗口函数
- 数据量大，中间结果集相对稳定（如按天统计的活跃用户）
示例（使用CTE）：
WITH user_stats AS (SELECT user_id, COUNT(*) cnt FROM log WHERE dt = '2024-06-01' GROUP BY user_id) SELECT u.name, us.cnt FROM user u LEFT JOIN user_stats us ON u.id = us.user_id;慎用SELECT子句中的标量子查询
这类子查询必须返回0或1行，否则报错；更严重的是，它会在主查询每行都执行一次，无法利用索引下推或并行优化。
改善方法：
- 确认业务是否真需要逐行调用——很多时候可通过JOIN提前关联好
- 确保子查询中的WHERE条件有高效索引（特别是关联字段）
- 考虑用窗口函数替代，比如用SUM() OVER(PARTITION BY ...)代替按组查汇总值
例如：给每个订单加客户等级字段，不要写成(SELECT level FROM cust WHERE id = o.cust_id)，而应直接JOIN客户表。
