相关子查询不直接导致全表扫描，而是因内层无索引且需逐行代入外层值而放大扫描代价；其性能取决于索引是否生效、类型是否一致、有无函数或or等索引失效操作，优化关键在于切断相关性或确保索引严格匹配。
相关子查询本身不“导致”全表扫描，它只是把内层无索引的扫描放大了 N 倍——N 是外层返回的行数。真正触发全表扫描的是内层查询没走索引，而相关性让这个代价被重复执行。
为什么相关子查询必然逐行重算
只要子查询里出现外层表的列（比如 u.department、o.user_id），数据库就无法提前算出结果。它必须等外层某一行进来后，把该行的值代入子查询再跑一遍。这不是优化器偷懒，是语义决定的。
- MySQL 5.7 及更早版本基本不物化相关子查询；8.0 虽支持简单聚合物化，但对
WHERE条件含函数、OR、类型转换等情况完全失效 - PostgreSQL 的
LATERAL语义相同，执行计划里会标为Correlated Subquery，同样依赖索引才能避免嵌套循环扫表 - EXPLAIN 中看到
DEPENDENT SUBQUERY且对应行的rows值很大（比如 50 万），同时外层预估仅 100 行 → 这就是 100 × 50 万次 I/O 的信号
内层没索引，等于每行都触发一次全表扫描
子查询是否走索引，和它是不是“子查询”无关，只取决于：字段类型是否一致、条件是否满足最左前缀、有没有对索引列做函数运算。常见失效场景：
-
user_id是VARCHAR，外层传数字123→ MySQL 隐式转成CAST(user_id AS SIGNED) = 123，key为NULL - 联合索引是
(status, created_at)，子查询写WHERE created_at > '2023-01-01'→key_len = 0，实际全表扫 -
WHERE YEAR(created_at) = 2023或WHERE status != 0→ 索引直接失效，优化器别无选择
IN / EXISTS 也逃不开这个逻辑，只是表现形式不同
IN 和 EXISTS 看似比相关子查询“高级”，但底层仍是相关执行模型。它们容易给人“已优化”的错觉，实则风险更隐蔽：
-
WHERE id IN (SELECT user_id FROM orders WHERE status = 1)：如果orders.user_id没索引，MySQL 会先物化子查询结果，再对外层每行做哈希查找；一旦内存不足或结果过大，降级为磁盘临时表 + 全表驱动 -
WHERE EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id AND (l.type = 'pay' OR l.code > 200))：OR让优化器放弃索引，DEPENDENT SUBQUERY被调用数千次，Extra里反复出现Using where却没Using index condition - 执行计划中若同时出现
Using temporary和Using filesort，说明物化失败+排序落地磁盘，性能已崩坏
改写比加索引更关键，但索引是前提
光建索引不够，因为相关子查询的结构会让优化器持续处于“不确定”状态。稳定解法是切断相关性：
- 用
JOIN + GROUP BY替代聚合类相关子查询：把(SELECT AVG(age) FROM users u2 WHERE u2.department = u.department)拆成独立子查询聚合，再JOIN回主表，确保内层只扫一次 - 用窗口函数替代“当前行上下文”类逻辑：比如查每个用户最新订单时间，
FIRST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time DESC)比相关子查询快一个数量级以上 - 真要保留子查询结构，至少确保：子查询里所有过滤字段都有单列或复合索引、类型严格一致、不用函数、不写
OR；然后手动ANALYZE TABLE更新统计信息——否则优化器仍可能误判成本
最容易被忽略的点是：你以为在调优 SQL，其实是在和过期的统计信息、隐式类型转换、联合索引顺序这三样东西较劲。验证永远从 EXPLAIN FORMAT=JSON 开始，而不是从“我写了索引”开始。
