dependent subquery慢是因为外层每行都重复执行子查询，如10万行则执行10万次；改写为join需满足单列依赖、无聚合、位置在where/select等前提，并验证去重和null逻辑。
子查询被重复执行，基本可以断定是相关子查询（DEPENDENT SUBQUERY）在作祟——外层每扫一行，它就真跑一次。这不是配置问题，是 SQL 语义和优化器能力共同决定的硬限制。
怎么一眼识别重复执行？
直接看 EXPLAIN 输出：
-
select_type列出现DEPENDENT SUBQUERY或DERIVED（尤其嵌套多层时） - 外层
rows是 10 万，子查询那行的rows也标着 10 万或更大 -
Extra出现Using where; Using temporary; Using filesort，且反复出现在多个层级
注意：MySQL 8.0+ 对部分非相关子查询会自动物化，但只要子查询里引用了外层字段（比如 WHERE o.user_id = u.id），就逃不开逐行执行。
为什么加索引也救不了？
索引只能加速单次查找，不能阻止“执行 10 万次”。常见误区：
- 给
users.status加了索引，但子查询写成WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid')→user_id没索引，内表仍全扫 - 复合条件漏掉前导列：
INDEX(status, user_id)有效，但INDEX(user_id, status)在WHERE status = 'paid'时用不上 - JOIN 条件字段类型不一致（如
INTvsVARCHAR），导致索引失效，退化为全表扫描
什么情况下必须改写为 JOIN？
满足以下任意一条，就该动手重写：
- 子查询出现在
WHERE中，且只返回单列（如user_id）、无GROUP BY、无聚合函数 - 语义是“存在性判断”（
IN/EXISTS）或“值匹配”（= (SELECT ...)） - 主表与子表是 1:N 关系，但你只关心主表逻辑（此时用
EXISTS比JOIN更安全）
典型改写示例：
SELECT * FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid');
→ 改为：
SELECT DISTINCT u.* FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
关键点：DISTINCT 防止一对多放大；WHERE 条件必须下推到 JOIN 后的表上，不能留在外层。
哪些情况不能硬套 JOIN？
盲目替换反而引入错误或更慢：
- 子查询含
LIMIT 1或ORDER BY created_at DESC（如“每个用户的最新订单”）→ 必须用窗口函数或派生表先聚合 - 子查询有
COUNT(*)、AVG(score)等聚合，且未按关联字段分组 → 改 JOIN 后必须加GROUP BY，且要确认是否需DISTINCT -
NOT IN子查询结果含NULL→ 直接转LEFT JOIN ... IS NULL会漏数据，得先WHERE xxx IS NOT NULL过滤
最隐蔽的坑：改完 SQL 结果对了，但 EXPLAIN 显示 type 变成 ALL —— 很可能 JOIN 字段没索引，或者统计信息过期，ANALYZE TABLE 比调优更管用。
