dependent subquery是性能杀手，因外层每行都重复执行子查询，导致10万行×3ms=300秒调度开销；改写为join可绕过重复扫描，但需确保语义等价、索引到位、null处理正确。
不是所有子查询改写为 JOIN 都能提速，但当出现 DEPENDENT SUBQUERY 或 type=ALL 且 rows 值远超结果集时，改写大概率有效——前提是语义可等价、索引到位、NULL 行处理得当。
为什么 DEPENDENT SUBQUERY 是性能杀手
MySQL 在遇到类似 WHERE u.id IN (SELECT user_id FROM logs WHERE action = 'login') 且无法物化子查询时，会把它当作相关子查询处理：外层每扫一行 u，就重新执行一次子查询。10 万用户 × 平均 3ms = 300 秒纯调度开销，不是算得慢，是反复启动慢。
- EXPLAIN 中
select_type显示DEPENDENT SUBQUERY就是明确信号 - 哪怕
logs.user_id有索引，也挡不住“10 万次单点查找”带来的随机 I/O 和上下文切换 - MySQL 5.6+ 的 semi-join 优化只在子查询结构干净（无
GROUP BY、LIMIT、ORDER BY）且预估行数小时才触发，别默认它开着
INNER JOIN 怎么绕过重复扫描
把逻辑从“逐行判断是否存在”变成“先批量关联再过滤”，让优化器有机会选 Hash Join 或 Index Nested-Loop：
- 子查询结果被当作驱动表（如
logs），若加了WHERE action = 'login'，过滤后可能只剩几百行 → 可哈希建表，主表users扫一次即可匹配 - 把条件下推到
ON子句：JOIN logs l ON u.id = l.user_id AND l.action = 'login'，MySQL 才可能用上(user_id, action)联合索引 - 若
users.id和logs.user_id类型不一致（比如前者是VARCHAR，后者是INT），隐式转换会让索引失效，Hash Join成为唯一选择——但内存不够时哈希表落盘，反而更慢
改写后数据对不上？三个语义坑必须填
语法改了，语义没对齐，轻则结果膨胀，重则漏数据：
-
IN天然去重，INNER JOIN遇到一对多（一个用户多条登录日志）会放大行数 → 加DISTINCT或确认业务允许重复 - 原逻辑是查“所有用户及其是否登录过”，却写了
INNER JOIN→ 直接丢掉没登录的用户；该用LEFT JOIN+l.user_id IS NOT NULL -
NOT IN (SELECT ...)含NULL时恒为UNKNOWN，整行被过滤；LEFT JOIN必须补AND l.user_id IS NOT NULL才等价，否则右表字段为NULL时仍保留左表行
真正起效的关键不在“写成 JOIN”，而在你是否盯住了 EXPLAIN ANALYZE
看到 Hash Join 不代表快，看到 rows 很小也不代表稳。必须检查：
-
Extra列有没有Using hash，且loops=1（说明哈希表只建一次） - 若
Created_tmp_disk_tables暴涨，说明哈希表内存溢出，得调大join_buffer_size或换回物化临时表 -
key列是否非空，type是否从ALL变成ref或eq_ref—— 这才是索引真正生效的证据
