为什么在SQL中关联子查询的执行次数会随着主表行数呈线性增长

关联子查询必须逐行执行，因其语义依赖外层表列（如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 次独立查询”。标量子查询的简洁语法，掩盖了它底层的暴力迭代本质。