DEPENDENT SUBQUERY慢是因为需为外层每行重复执行，导致N×M嵌套循环扫描，且常无法利用索引；满足标量返回、相关列依赖、无不可下推逻辑时可安全改写为JOIN，并注意NULL处理、重复行和条件迁移。
为什么DEPENDENT SUBQUERY会慢
MySQL遇到 DEPENDENT SUBQUERY 时，意味着子查询要为外层每一行重复执行一次，本质上是嵌套循环（N×M）。即使外层只有1000行，子查询里查的表有10万行，最坏可能触发1亿次扫描。更糟的是，这类子查询通常无法利用外层字段上的索引做关联优化，优化器也常放弃使用子查询里的索引。
什么情况下能安全改写成JOIN
只要子查询满足以下全部条件，就大概率可转为 JOIN：
- 子查询出现在
SELECT列表或WHERE子句中，且只返回单个值（标量）或最多一行（如用MAX()、MIN()、EXISTS改写后） - 子查询的
WHERE条件依赖外层表的某一列（即存在相关列，如t1.id = t2.t1_id） - 子查询不包含不能下推的逻辑：比如未加
LIMIT 1的无序ORDER BY ... LIMIT、聚合后没GROUP BY外键、或引用了外层多层嵌套的列
典型可改写结构：(SELECT name FROM users u WHERE u.id = o.user_id) → 可用 LEFT JOIN users u ON o.user_id = u.id 替代。
改写时必须处理的三个细节
直接把子查询换成 JOIN 很容易出错，尤其在语义和结果一致性上：
-
NULL 值行为差异：原
SELECT (SELECT x FROM t2 WHERE t2.id = t1.id)对找不到匹配的t1行返回NULL；若用INNER JOIN就直接丢弃该行，必须改用LEFT JOIN并显式写u.x -
重复行放大问题：如果
t2对一个t1.id有多条匹配记录，JOIN会让t1行重复出现；此时需加GROUP BY t1.id或用MAX()/MIN()/ANY_VALUE()聚合，否则结果行数爆炸 -
WHERE 条件迁移陷阱：原子查询中带额外过滤（如
AND status = 'active'），这个条件必须移到ON子句里（不是WHERE），否则会把LEFT JOIN变成INNER JOIN效果
错误示例：LEFT JOIN users u ON u.id = o.user_id WHERE u.status = 'active' → 实际过滤掉了所有 user_id 不匹配的订单；正确应为：LEFT JOIN users u ON u.id = o.user_id AND u.status = 'active'。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
EXISTS/NOT EXISTS 怎么对应改写
这类子查询虽然也标 DEPENDENT SUBQUERY，但语义是布尔判断，改写为 JOIN 反而低效，优先转成 LEFT JOIN ... IS NOT NULL 或保留（现代 MySQL 8.0+ 对 EXISTS 优化已较好）：
原写法：WHERE EXISTS (SELECT 1 FROM orders o2 WHERE o2.user_id = u.id AND o2.created_at > '2024-01-01')
改写建议：LEFT JOIN orders o2 ON o2.user_id = u.id AND o2.created_at > '2024-01-01'，再在 WHERE 加 o2.user_id IS NOT NULL；注意别漏掉 AND 后的条件进 ON，否则又变成交叉连接。
真正难处理的是子查询里含窗口函数、变量或依赖执行顺序的逻辑——这种基本没法用 JOIN 等价替换，得拆成临时表或应用层分步处理。
