SQL子查询性能取决于写法、数据量、索引和执行计划；应优先用JOIN替代相关子查询，善用EXISTS替代IN/NOT IN，并通过EXPLAIN分析瓶颈，必要时物化子查询。
SQL 子查询本身不必然慢，性能好坏取决于写法、数据量、索引设计和执行计划。很多“慢”的子查询其实是可以被重写或优化的，关键在于识别瓶颈类型并针对性处理。
识别子查询是否真的拖慢查询
先用 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）查看执行计划，重点关注：
- 子查询是否被标记为 DEPENDENT SUBQUERY（MySQL）或反复执行（如 Nested Loop）
- 是否出现全表扫描（type=ALL）、未使用索引（key=NULL）或临时表/文件排序（Using temporary / Using filesort）
- 子查询是否在 WHERE 或 SELECT 列中，执行频次差异极大：WHERE 中的标量子查询可能每行执行一次；SELECT 中的标量子查询也可能被优化为物化，但大结果集下仍风险高
优先用 JOIN 替代相关子查询
当子查询用于关联主表某字段（如 WHERE id IN (SELECT user_id FROM logs WHERE ...) 或 SELECT (SELECT name FROM users u WHERE u.id = o.user_id)），多数情况可改写为 LEFT JOIN 或 INNER JOIN，让优化器统一规划连接策略。
- 避免
IN (SELECT ...)：改用JOIN或EXISTS（尤其子查询结果大时，IN 易触发全量枚举） - 避免 SELECT 中的标量子查询：提取为 JOIN，例如把
SELECT id, (SELECT status_name FROM statuses s WHERE s.id = o.status_id)改为SELECT o.id, s.status_name FROM orders o LEFT JOIN statuses s ON o.status_id = s.id - 注意 NULL 处理：JOIN 后需确认是否保留 NULL（用 LEFT JOIN）还是过滤掉（INNER JOIN），语义需与原逻辑一致
善用 EXISTS 替代 IN / NOT IN
当只需判断存在性（而非取值），EXISTS 通常比 IN 更高效，尤其子查询表较大且有合适索引时：
-
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.created_at > '2024-01-01')可提前终止，找到一行即返回 true -
NOT IN在子查询含 NULL 时会整体返回空结果（三值逻辑陷阱），而NOT EXISTS行为确定、更安全 - 确保子查询中关联字段（如
o.user_id = u.id）上有索引，否则 EXISTS 也会退化为全表扫描
物化子查询与临时表辅助
对复杂、固定条件的子查询（如统计中间结果），可主动物化以避免重复计算：
- MySQL 8.0+ 支持 WITH 子句（CTE），配合 MATERIALIZED 提示（如
WITH cte AS (SELECT ...)）可显式控制物化行为 - PostgreSQL 自动物化 CTE（除非加
NOT MATERIALIZED），适合复用中间结果 - 极复杂场景可建临时表（
CREATE TEMP TABLE），加索引后再 JOIN，适合子查询结果集大且多处引用的情况
