子查询性能问题主要体现为三类：一是相关子查询被重复执行导致N×M级开销，应改用JOIN+聚合预计算；二是子查询返回大量中间结果引发全表扫描或临时表落盘，需加索引、限制字段和改写为JOIN；三是函数包裹或隐式转换使索引失效，应将函数移至比较值侧。

子查询被重复执行（尤其是相关子查询）

当子查询依赖外部查询的每一行数据时，数据库会为每一行重新执行一次子查询，导致 N×M 级别开销。比如 WHERE salary > (SELECT AVG(salary) FROM employees WHERE dept_id = e.dept_id)，如果外层有 1000 行，且每个部门都不同，这个子查询可能被执行 1000 次。

• 用 JOIN + 聚合预计算替代：先算好每个部门的平均工资，再关联
• 检查执行计划中是否出现 DEPENDENT SUBQUERY（MySQL）或 Correlated Subquery（PostgreSQL）字样
• 在 MySQL 中，EXPLAIN FORMAT=TREE 能更清晰看到嵌套执行层级

子查询返回大量中间结果（未加 LIMIT 或过滤）

像 SELECT * FROM o

rders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'Asia')，若子查询返回 50 万客户 ID，IN 列表可能膨胀成巨大集合，触发全表扫描或临时表落盘。

• 确保子查询有高效索引：比如 customers(region, id) 覆盖索引
• 避免在子查询中使用 SELECT *，只选必要字段
• PostgreSQL 对大 IN 列表会自动转为哈希连接，但 MySQL 8.0.19+ 才开始优化，老版本建议改写为 JOIN

子查询无法利用索引（常见于函数包裹或类型隐式转换）

一旦子查询里对字段用了函数或表达式，索引大概率失效。例如 SELECT name FROM users WHERE id IN (SELECT user_id FROM logs WHERE DATE(created_at) = '2025-01-01')，DATE() 会让 created_at 索引失效。

• 把函数移到右边：改用 created_at >= '2025-01-01' AND created_at
• 确认子查询字段和外层比较字段类型一致，避免隐式转换（如字符串和数字比较）
• 用 EXPLAIN 查看 key 和 rows 字段，若 key 为 NULL 就说明没走索引

子查询嵌套过深或混用多种类型（标量子查询 + EXISTS + IN）

多层嵌套（尤其跨 3 层以上）会让优化器难以生成高效计划；混合使用 EXISTS、IN、标量子查询还可能触发不同执行路径，增加计划不稳定性。

• 超过 2 层嵌套时，优先考虑 CTE 拆解（WITH），提升可读性和优化器可见性
• EXISTS 通常比 IN 更适合判断存在性，尤其子查询结果含 NULL 时行为更可控
• 标量子查询（返回单值）若可能为空，注意 NULL 参与比较会导致整行被过滤（WHERE col = (SELECT ...) 遇到子查询返回 NULL 时结果为 UNKNOWN）

实际调优时，最常被忽略的是子查询的“执行时机”——它未必像看起来那样只跑一次，也未必总比 JOIN 慢；关键得看执行计划里它到底怎么跑、跑多少次、扫了多少行。