dependent subquery说明该子查询是相关子查询，依赖外层表列，优化器无法物化，必须对外层每行重复执行；常见于exists、in或标量子查询中引用外层字段的场景。
EXPLAIN里出现DEPENDENT SUBQUERY说明什么
这表示优化器判定该子查询是相关子查询（correlated subquery），即内层引用了外层表的列，无法一次性物化执行。MySQL或PostgreSQL会把它理解为“每处理一行外层数据，就要重新跑一次子查询”。不是它“故意慢”，而是语义决定了它必须逐行评估——EXPLAIN里的DEPENDENT SUBQUERY就是这个行为的明确标记。
- 常见触发场景：
WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref_id)、WHERE t1.val > (SELECT AVG(val) FROM t2 WHERE t2.group_id = t1.group_id) - 注意：即使子查询看起来简单，只要引用了外层别名（如
t1.ref_id），就大概率被标为DEPENDENT - PostgreSQL中对应提示是
SubPlan或InitPlan节点，配合Actual Rows明显放大可确认重复执行
为什么优化器不自动改写成JOIN
优化器能否把相关子查询转成JOIN，取决于语义是否等价且条件是否可下推。一旦子查询里包含GROUP BY、HAVING、聚合函数（AVG/COUNT）、LIMIT或不可下推的表达式（如DATE_FORMAT(created_at, '%Y')），半连接（semi join）或反连接（anti join）路径就会失效，只能退回到逐行执行。
- 例如：
WHERE EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id AND COUNT(*) > 5)——COUNT让优化器无法合并，必然DEPENDENT - 再如：
WHERE u.id IN (SELECT user_id FROM orders GROUP BY user_id HAVING SUM(amount) > 1000)——GROUP BY + HAVING阻断了物化和下推 - MySQL 5.7+ 和 PostgreSQL 12+ 对简单
EXISTS/IN支持较好，但复杂逻辑仍需人工干预
用JOIN重写时最容易踩的三个坑
不是所有相关子查询都能无损转成JOIN；强行替换可能改变结果集语义，或引入重复行、NULL值等副作用。
- 用
INNER JOIN替代EXISTS没问题，但替代NOT EXISTS必须用LEFT JOIN ... IS NULL，漏掉IS NULL判断会导致逻辑错误 -
IN子查询天然去重，而JOIN可能因一对多关系产生重复外层行，必须加DISTINCT或改用SEMI JOIN语义（PostgreSQL可用IN保留原意，MySQL需手动去重） - 子查询返回
NULL时，IN (subquery)整行会被过滤掉；但JOIN后若没处理NULL关联字段，可能意外保留或丢失数据
什么时候不该硬改成JOIN
如果子查询只涉及极小结果集（比如SELECT id FROM config WHERE key = 'feature_flag'），或外层数据本身极少（
- 典型安全场景：配置表查询、单值查找、状态码映射等静态小表子查询
- 验证方法：对比
EXPLAIN ANALYZE的Actual Total Time和Actual Rows，看内层执行次数是否真成为瓶颈 - PostgreSQL中若子查询被标记为
InitPlan且Actual Rows恒为1，基本可放心保留
DEPENDENT SUBQUERY或SubPlan，第一反应不应该是删掉子查询，而是确认：它的重复执行是不是必要？能不能把计算提前到外层聚合？或者换种语义更清晰的写法（比如CTE预计算）？这些细节比“一律JOIN化”更能守住边界。
