关联子查询必须逐行执行，因其语义依赖外层表列（如e1.dept_id），运行时才能获取当前行值，优化器无法预计算，只能走嵌套循环，导致n次重复执行。
关联子查询为什么必须逐行执行
因为它的语义决定了它不能提前算出结果：子查询里引用了外部表的列（比如 e1.dept_id），而外层表每扫到一行，这个值就可能不同。数据库没法“猜”出所有可能的 e1.dept_id 值再预计算，只能等运行时拿到当前行的值，再执行一次子查询。
这不是缓存没配好，也不是SQL写得不够优雅——这是执行引擎对“相关性”的硬性承诺。只要子查询里出现 WHERE b.a_id = a.id 这类跨层引用，优化器就放弃物化，直接走嵌套循环路径。
MySQL 和 PostgreSQL 都默认走 Nested Loop
MySQL 5.7 及之前版本基本不尝试去关联化（decoupling）；8.0 虽支持部分标量子查询自动重写为 LEFT JOIN，但仅限无聚合、单表、无函数的简单场景。一旦子查询含 COUNT(*) 或多表 JOIN，优化器大概率放弃重写。
PostgreSQL 在 12+ 版本虽引入 LATERAL 和 unnest 优化，但遇到 WHERE x IN (SELECT ...) 或标量形式，仍常退化为 loop join。EXPLAIN 中看到 Dependent Subquery 或 Correlated Subquery，基本等于宣告“每行必调用一次”。
- 外层主表返回 10 万行 → 子查询执行 10 万次
- 哪怕子查询只查 5 行小表，每次仍要走解析、计划生成、索引查找、回表全流程
- 总耗时 ≈ 单次耗时 × 主表行数，不是“慢一点”，是“线性放大”
索引在子查询里容易失效，加剧线性恶化
即使你给子查询涉及的字段建了索引，也可能白搭。真正起作用的是子查询内部的过滤条件能否高效走索引，而不是外层有没有索引。
常见失效原因：
- 子查询中用了函数，比如
DATE(login_time)，导致索引无法命中 - 等值字段类型不一致，比如
INT对VARCHAR，触发隐式转换 - 子查询返回大量行，优化器判断走索引成本更高，直接改全表扫描
-
key_len明显偏小（如联合索引三列，只用了第一列），说明最左前缀没对齐
怎么一眼确认它正在拖垮性能
别等用户投诉。直接看执行计划中最容易暴露问题的三个信号：
-
type列出现ALL或index，且对应行的Extra含Using where - 出现
DEPENDENT SUBQUERY或UNCACHEABLE SUBQUERY，且该行rows值远大于外层预估行数 - 执行
EXPLAIN FORMAT=JSON，重点盯dependent_contexts字段是否为空 —— 不为空，就是实锤
真正棘手的从来不是“能不能写出来”，而是“有没有意识到这行代码正在后台发起 N 次独立查询”。标量子查询的简洁语法，掩盖了它底层的暴力迭代本质。
