子查询本身不直接“优化”查询，它更多是逻辑表达工具；真正提升性能的关键在于：用对场景、避免嵌套过深、配合索引，并在必要时改写为连接（JOIN）或临时表。盲目使用子查询反而容易拖慢速度。
哪些情况适合用子查询
子查询在语义清晰、逻辑分层明确的场景下很实用，比如：
结果集过滤：如“查出销售额高于平均值的员工”，用(SELECT AVG(sales) FROM employees)做条件比先算均值再拼SQL更简洁； 存在性判断：用
EXISTS替代
IN处理大表关联，尤其当子查询可提前终止时（例如检查某客户是否有订单）； 单值计算字段：在 SELECT 列表中嵌入聚合子查询，如
(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id)统计每个用户的订单数（注意：该写法在数据量大时可能变慢，需评估）。
哪些情况要避免或改写子查询
以下结构容易引发性能问题，建议重构：
相关子查询无索引支撑：比如WHERE id IN (SELECT user_id FROM logs WHERE action='login')，若
logs.action没有索引，每次外层扫描都要全表查日志表；应为
action和
user_id建联合索引，或改用 LEFT JOIN； 多层嵌套（>2 层）：MySQL 对深层子查询优化能力有限，执行计划常退化为嵌套循环；可拆成中间临时表或 CTE（MySQL 8.0+ 支持）； SELECT 中的标量子查询被重复执行：如对 10 万行用户查各自最新订单时间，
(SELECT created_at FROM orders WHERE user_id = u.id ORDER BY id DESC LIMIT 1)会执行 10 万次；改用窗口函数（
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)）或先聚合再 JOIN 更高效。
常用优化替代方案
不是所有子查询都要删，但多数可等价转换为更可控的形式：
IN → JOIN 或 EXISTS：`WHERE id IN (SELECT user_id FROM active_users)` 改为 `INNER JOIN active_users au ON t.id = au.user_id`（需去重加 DISTINCT）或 `EXISTS (SELECT 1 FROM active_users au WHERE au.user_id = t.id)`； 聚合子查询 → 窗口函数或派生表：统计每个部门平均工资并标记高于均值的员工，可用AVG() OVER(PARTITION BY dept)一步完成，无需子查询； 复杂条件 → WITH 语句预计算（MySQL 8.0+）：把多次引用的子查询定义为 CTE，让优化器有机会复用结果，也提升可读性。
验证是否真的优化了
别只看执行时间，重点看执行计划：
用EXPLAIN FORMAT=TREE（MySQL 8.0）或
EXPLAIN查看是否出现
DEPENDENT SUBQUERY（相关子查询）或
UNCACHEABLE SUBQUERY（无法缓存）； 关注
rows和
filtered列：如果子查询预估扫描行数远超实际需要，说明缺少索引或条件未下推； 对比改写前后
Handler_read_*状态变量，尤其是
Handler_read_next是否显著下降——反映索引利用效率提升。
子查询是 SQL 表达力的重要部分，但不是性能银弹。核心思路是：优先让数据走索引，减少重复计算，把逻辑复杂度交给数据库优化器处理，而不是堆砌嵌套。
