子查询性能问题主要体现为三类：一是相关子查询被重复执行导致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 orders 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) = '2024-01-01')，DATE() 会让 created_at 索引失效。
- 把函数移到右边：改用
created_at >= '2024-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 慢；关键得看执行计划里它到底怎么跑、跑多少次、扫了多少行。
