相关子查询性能差因每行重复执行，优化应转为 join、窗口函数或临时表；可改写场景包括 exists→left join、聚合→group by、同组计算→窗口函数；必要时加索引并限行。
相关子查询性能差，核心原因是它在外部查询的每一行上都执行一次内部查询，导致重复计算和大量 I / O 开销。优化的关键不是“避免所有子查询”，而是识别可转换为连接（JOIN）或使用窗口函数、临时表等更高效结构的场景。
识别可改写为 JOIN 的相关子查询
当子查询只依赖外部表的某几个字段（如 WHERE t1.id = t2.t1_id），且返回单值（如MAX()、COUNT()）或用于EXISTS/NOT EXISTS 判断时，大概率能转为 LEFT JOIN 或 INNER JOIN。
- EXISTS → LEFT JOIN + IS NOT NULL：把
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.cust_id AND c.status = 'active')改为SELECT DISTINCT o.* FROM orders o LEFT JOIN customers c ON o.cust_id = c.id AND c.status = 'active' WHERE c.id IS NOT NULL - 聚合子查询 → LEFT JOIN + GROUP BY：例如
SELECT name, (SELECT COUNT(*) FROM orders WHERE cust_id = c.id) cnt FROM customers c可改写为SELECT c.name, COALESCE(o.cnt, 0) cnt FROM customers c LEFT JOIN (SELECT cust_id, COUNT(*) cnt FROM orders GROUP BY cust_id) o ON c.id = o.cust_id
用窗口函数替代部分标量子查询
当子查询用于计算同组内的聚合值（如每个订单的客户总订单数、当前订单在客户订单中的序号），窗口函数比相关子查询快一个数量级，且逻辑更清晰。
- 原写法：
SELECT order_id, cust_id, (SELECT COUNT(*) FROM orders o2 WHERE o2.cust_id = o1.cust_id) AS total_per_cust FROM orders o1 - 优化后：
SELECT order_id, cust_id, COUNT(*) OVER (PARTITION BY cust_id) AS total_per_cust FROM orders - 注意：窗口函数不能替代含复杂过滤条件（如子查询中带
WHERE …… AND date > ……）的场景，需结合具体业务逻辑评估
临时表 /CTE 预计算中间结果
若相关子查询逻辑固定但涉及多表关联或耗时计算（如统计近 30 天活跃用户数），可先将结果物化，再与主表关联。
- 用 CTE 提前算好：
WITH active_users AS (SELECT user_id FROM events WHERE event_time >= NOW() - INTERVAL '30 days' GROUP BY user_id)，后续在主查询中直接LEFT JOIN active_users - 对大数据量，考虑建物化临时表并加索引（如
CREATE TEMP TABLE tmp_active_users AS ……; CREATE INDEX ON tmp_active_users(user_id);） - 避免在 CTE 中写过于宽泛的查询（如没加时间范围），否则预计算反而拖慢整体响应
必要时保留子查询，但加索引和限制返回
并非所有子查询都必须改写。若子查询本身已高度过滤、返回结果极少，且无法通过 JOIN 等价表达（如依赖外部行做动态日期计算），应聚焦于提升其自身效率。
- 确保子查询中的关联字段、WHERE 条件字段都有合适索引（如
(cust_id, status, created_at)联合索引） - 用
TOP 1（SQL Server）、LIMIT 1（PostgreSQL/MySQL）显式限制返回行数，尤其在EXISTS语义下，避免全表扫描 - 检查执行计划，确认子查询是否走了索引查找（Index Seek）而非扫描（Index Scan）
