嵌套查询能用但多为过渡方案，应拆为中间表或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流程要稳，就得把“这段逻辑在哪跑、谁来算、中间结果存哪”想清楚，而不是只盯着语法对不对。
