dependent subquery 是性能红灯，意味着主表每行都重执行子查询，分布式环境下引发跨节点rpc、shuffle和缓存失效，需用left join（on中写过滤条件）、exists替代in、物化汇总表等方案优化。
相关子查询被标记为 DEPENDENT SUBQUERY 就等于性能红灯
只要 EXPLAIN 输出里出现 DEPENDENT SUBQUERY，说明数据库对主表每行都重新执行一次子查询——100 万行用户？就调 100 万次子查询。这不是“慢一点”，是计算量爆炸式增长。
在分布式库（如 TiDB、StarRocks、Doris）中更危险：每次子查询都可能触发跨节点 RPC、数据 shuffle、序列化开销，而这些操作无法被缓存或复用。
- MySQL 单机尚可靠连接池和本地缓存扛一扛；分布式环境下，子查询的重复执行直接变成网络与调度瓶颈
- 优化器很难准确估算分布式子查询代价，常误选 Broadcast Join 而非 Shuffle Join，导致小表被广播到所有节点，内存溢出
- 子查询里带函数（
NOW()、UUID()）、变量或参数时，几乎必然无法物化，强制依赖运行时值
LEFT JOIN 改写不是“能用就行”，而是必须控制 ON 条件位置
把 SELECT (SELECT name FROM users WHERE id = o.user_id) 改成 LEFT JOIN users u ON u.id = o.user_id 是基础，但容易踩坑：
- 如果原意是 “只取 status = 'active' 的用户”，错误写法：
WHERE u.status = 'active'→ 实际变成 INNER JOIN 效果，丢失无匹配订单的记录 - 正确写法：条件必须放进
ON u.id = o.user_id AND u.status = 'active' - 分布式库对
USING支持不一，务必显式用ON+ 表前缀（如o.user_id），避免列名歧义引发计划错误 - JOIN 后若需去重（比如一对多导致订单行翻倍），不能靠
DISTINCT补救——应提前聚合，例如用MAX(u.name)或ANY_VALUE(u.name)
EXISTS 替代 IN 时，NULL 处理和谓词下推是关键
写 WHERE id IN (SELECT user_id FROM log WHERE type = 'login') 在分布式库中极易出错：
-
IN遇到子查询返回NULL时整体判为UNKNOWN，结果集为空——业务逻辑悄然失效 - 分布式引擎常无法把
type = 'login'下推到子查询所在节点，导致全量拉取再过滤，网络带宽打满 - 改用
EXISTS后，确认执行计划里type条件是否出现在子查询的WHERE中（而非被提升到外层） - 某些引擎（如 Doris）对
EXISTS自动启用 Semi-Join 优化；TiDB 则依赖统计信息质量，必要时加/*+ USE_INDEX(log, idx_type_user) */
CTE 或物化临时表不是银弹，要看数据分布和刷新频率
面对高频、稳定、计算重的子查询（比如“每个省份近 7 日 GMV”），直接提成 CTE 或建临时表看似合理，但：
- CTE 在多数分布式库中默认不物化（TiDB 除外），只是语法糖，嵌套越深，计划越不可控
- 临时表要显式指定分片键（如
DISTRIBUTED BY HASH(user_id)），否则数据倾斜，单节点 CPU 100% - 如果子查询结果每天只变一次，不如用定时任务写入汇总表，查时走单点索引；比实时 JOIN 省 90% 资源
- 物化视图（如 StarRocks 的
MATERIALIZED VIEW）要求基表更新频繁度低，且需手动REFRESH，别指望它自动同步
真正卡住性能的，往往不是 SQL 写法本身，而是没看清数据在哪、算力在哪、网络在哪断——分布式环境里，子查询慢的本质，是把单机思维直接搬进了多节点协同的物理世界。
