相关子查询是mysql典型性能陷阱，外层每行触发内层重执行；遇dependent subquery需警觉，应优先用exists或inner join重写，并确保关联字段有合适复合索引。
相关子查询（correlated subquery）是MySQL里最典型的性能陷阱之一——它不是“执行一次、复用结果”，而是外层每查一行，内层就重跑一遍。数据量稍大，比如外层10万行，子查询就得执行10万次，不慢才怪。
为什么EXPLAIN看到DEPENDENT SUBQUERY就该警觉
执行EXPLAIN时，如果子查询的select_type显示为DEPENDENT SUBQUERY，说明优化器已判定该子查询依赖外层字段，无法物化或提前计算。这不是警告，是确诊书。
- 它会强制走嵌套循环：外层表扫描多少行，子查询就完整执行多少次
- 哪怕子查询本身加了索引，每次执行仍要回表、判断、过滤，开销叠加
- 若子查询含
ORDER BY、LIMIT或聚合函数，还可能触发Using filesort或Using temporary，进一步拖慢 - MySQL 5.7及之前版本对此类场景基本无自动优化能力；8.0虽引入部分semi-join优化，但对复杂条件仍常退回到依赖模式
用EXISTS重写是最直接有效的解法
当你的原始语句是判断“是否存在匹配”，比如WHERE EXISTS (SELECT 1 FROM logs WHERE logs.user_id = users.id AND ...)，EXISTS天然适配这种语义，且只找第一条就停。
- 确保子查询中关联字段（如
logs.user_id）有索引，否则EXISTS也快不起来 - 子查询里别写
SELECT *或多余字段，SELECT 1足够；也不用LIMIT 1，EXISTS自己会做 - 注意
NOT EXISTS和NOT IN的NULL行为差异：NOT IN遇子查询返回NULL整行失效，NOT EXISTS不受影响 - 如果原逻辑是“取用户信息 + 同时满足日志条件”，而你只改
WHERE部分，SELECT字段和JOIN语义没变，风险最低
INNER JOIN替代适用于“取交集记录”场景
如果你实际要的是“用户及其对应的有效日志记录”，而不是“判断用户有没有日志”，那INNER JOIN比EXISTS更自然，也更容易利用哈希连接。
- 原写法：
SELECT u.* FROM users u WHERE u.id IN (SELECT user_id FROM logs WHERE status='success') - 改写后：
SELECT DISTINCT u.* FROM users u INNER JOIN logs l ON u.id = l.user_id WHERE l.status = 'success' - 必须加
DISTINCT或用GROUP BY，否则一个用户多条日志会导致结果重复——这点和IN的隐式去重不等价 - 若子查询本身含
GROUP BY或HAVING，不要硬套JOIN，优先考虑派生表：SELECT u.* FROM users u INNER JOIN (SELECT user_id FROM logs GROUP BY user_id HAVING COUNT(*) > 3) t ON u.id = t.user_id
容易被忽略的关键点：执行顺序与索引覆盖
所有优化的前提，是让MySQL先过滤出尽可能小的结果集再关联。这取决于WHERE条件位置和索引设计，而不是你写了JOIN还是EXISTS。
- 在
JOIN写法中，把高选择性过滤条件（如status = 'active'）放在驱动表（通常是JOIN左边那个）的WHERE里，才能真正减少扫描量 -
EXISTS子查询中的条件，必须能命中索引前缀；例如WHERE logs.user_id = u.id AND logs.created_at > '2026-01-01'，索引得是(user_id, created_at)，反过来无效 - 别迷信“改写完就快了”——务必用
EXPLAIN FORMAT=JSON确认rows_examined是否显著下降，以及key列是否用了预期索引
