嵌套查询能用但多为过渡方案，应拆为中间表或cte；mysql中not in遇null返回空需改用not exists；pg需显式控制materialized；spark sql中相关子查询需3.0+支持，旧版应转join或array_contains。

嵌套查询在ETL中该不该用？

能用，但多数时候是过渡方案——真正跑得稳的ETL流程，会把嵌套查询拆成中间表或CTE。因为嵌套查询在数据量稍大时，容易触发执行计划退化，尤其在MySQL 5.7或旧版PostgreSQL里，WHERE ... IN (SELECT ...)可能被重写成低效的嵌套循环。

• 场景明确：清洗逻辑依赖上游结果（比如“只保留近30天有订单的用户”），且上游数据集不大（
• 风险点：嵌套层超过2层、子查询含GROUP BY或ORDER BY、外层JOIN后又套子查询
• 替代优先级：CTE > 临时表 > 嵌套查询（注意：MySQL 5.7不支持CTE，得降级用临时表）

MySQL里NOT IN导致结果为空的坑

这是ETL清洗中最隐蔽的错误之一：当子查询返回NULL时，NOT IN整个表达式直接判为UNKNOWN，最终过滤掉所有行。你查不到数据，不是没匹配上，是SQL三值逻辑把你“静音”了。

• 典型现象：SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders) 返回空结果，但明明有未下单用户
• 根因：子查询里user_id列存在NULL（比如日志表脏数据、LEFT JOIN补空值）
• 解法只有两个：NOT EXISTS 或 在子查询加 WHERE user_id IS NOT NULL
• 性能提示：NOT EXISTS通常比NOT IN快，且语义更安全，推荐无条件替换

PostgreSQL中嵌套查询与MATERIALIZED的关系

PG 12+默认对子查询做“自动物化”，但ETL流程里你得主动控制——否则清洗任务在不同环境表现不一致。比如开发库小数据走哈希连接很快，生产库大数据却因物化失败回退到嵌套循环，耗时暴涨十倍。

• 显式控制物化：在WITH子句里加MATERIALIZED（PG 12+）或NOT MATERIALIZED（PG 14+）
• 关键判断点：子查询结果是否会被多次引用？是否涉及窗口函数或排序？如果是，强制MATERIALIZED更稳
• 兼容性注意：PG 11及更早版本不识别MATERIALIZED关键字，会报错，需提前检查版本
• 示例：WITH clean_orders AS MATERIALIZED (SELECT * FROM raw_orders WHERE status = 'paid')

嵌套查询在Spark SQL里的等价写法问题

Spark SQL不完全兼容传统SQL语义，特别是相关子查询（correlated subquery）。你写的WHERE x IN (SELECT y FROM t2 WHERE t2.id = t1.id)在Spark 3.0+才支持，老版本直接报Unsupported SubQuery Expression。

• 常见报错：org.apache.spark.sql.AnalysisException: Correlated scalar subquery is not supported
• 实操路径：优先转成LEFT JOIN + IS NULL，或用collect_set()聚合后array_contains()判断
• 性能差异：collect_set会触发Shuffle，大数据量下不如JOIN稳定；但小维度表（
• 别踩的坑：Spark里IN子查询若右侧超2000个值，会自动转成广播JOIN，但若广播失败就fallback到慢速方式——建议手动控制广播阈值

嵌套查询本身不难写，难的是它在不同引擎里像变色龙：同一段SQL，在MySQL里秒出结果，在Spark里挂起，在PG里执行计划飘移。ETL流程要稳，就得把“这段逻辑在哪跑、谁来算、中间结果存哪”想清楚，而不是只盯着语法对不对。