关联子查询为什么每次外层行都执行一遍？
因为它的语义决定了它不能提前算出结果：子查询里引用了外部表的列（比如 e1.dept_id），而外层表每扫到一行，这个值就可能不同。数据库没法“猜”出所有可能的 e1.dept_id 值再预计算，只能等运行时拿到当前行的值，再执行一次子查询。
MySQL 5.7 及之前版本的嵌套循环模型是主因
老版本优化器对关联子查询基本不做去关联化（decoupling），默认走 Nested-Loop 执行路径：
- 外层表扫描第 1 行 → 执行子查询（带
WHERE e2.dept_id = 当前行 dept_id） - 外层表扫描第 2 行 → 再执行一遍子查询（条件值变了）
- ……直到外层表扫完
如果外层有 10 万行，子查询就真跑 10 万次 —— 即使子查询本身只查一张小表，叠加起来 I/O 和 CPU 开销也极可观。
EXISTS / IN / 标量子查询的执行行为差异
不是所有关联子查询都一样慢，关键看类型和优化器是否能“短路”：
-
EXISTS类：找到第一条匹配就停，适合“是否存在”的判断，相对友好 -
IN类：必须收集全部结果才能比对，容易触发临时表 + 全量扫描 - 标量子查询（如
SELECT ... WHERE salary > (SELECT AVG(...) FROM ...)）：必须返回且仅返回一行一列，否则报错；但每次仍要重新算，无法缓存
用 EXPLAIN 看执行计划时，如果看到 select_type 是 DEPENDENT SUBQUERY，就说明它被识别为关联子查询，且大概率没被优化掉。
最容易被忽略的性能陷阱：索引在子查询里失效
即使你给子查询涉及的字段建了索引，也可能白搭：
- 子查询中用了函数（如
DATE(login_time)）或表达式，导致索引无法命中 - 子查询的
WHERE条件里，等值字段类型不一致（比如INT对VARCHAR），触发隐式转换 - 子查询返回大量行，优化器放弃使用索引，改走全表扫描
真正起作用的，是子查询内部的过滤条件能否高效走索引 —— 而不是外层有没有索引。
