presto的cross join更危险，因其不支持where条件下推、无行级剪枝，笛卡尔积全程在分布式内存中展开，易触发oom；必须用cte或子查询前置过滤至单表≤1万行，并通过explain确认outputrowcount在千行级以内。

直接停用不带过滤的 CROSS JOIN，它不是慢，是必然触发OOM——尤其在Presto里没有行级剪枝机制，笛卡尔积全程在内存中展开。

为什么Presto的CROSS JOIN比其他引擎更危险？

Presto默认不支持WHERE条件下推到CROSS JOIN任一侧，也不会提前物化或裁剪中间结果。一旦左表10万行、右表50万行，就硬算500亿行组合，全部保留在分布式内存中，直到GC撑不住触发OutOfMemoryError: Java heap space。

• query.max-memory-per-node和query.max-total-memory-per-node只限制单节点总内存，但笛卡尔积会跨Worker广播全量右表数据，实际内存占用远超配置值
• 即使加了LIMIT，Presto也必须先完成全部连接再截断，LIMIT不生效于JOIN阶段
• EXPLAIN输出里若看到ExchangeNode类型为GATHER或REPLICATE，且OutputRowCount显示数量级爆炸（如1e10），就是已坐实笛卡尔积

怎么安全地替代CROSS JOIN？

核心原则：把“全量交叉”转为“按需拉取”，用子查询或CTE强制前置过滤，确保左右表都缩小到可控规模（建议单表≤1万行）。

• 用WITH先筛小表：WITH filtered_a AS (SELECT id FROM a WHERE dt = '2026-08-26' LIMIT 1000), filtered_b AS (SELECT code FROM b WHERE is_active) SELECT * FROM filtered_a CROSS JOIN filtered_b
• 避免SELECT *，只选必要字段；大文本字段（如description）必须用substr(description, 1, 100)或哈希化（md5(description)）
• 如果业务真需要枚举组合，改用UNION ALL构造确定行数的维度表，例如(VALUES ('Q1', 1), ('Q2', 2)) AS quarters(q, n)
• 严禁对events、logs、user_profiles这类宽表或滚动表做CROSS JOIN

查到正在跑的高危CROSS JOIN怎么紧急止损？

别等OOM killer杀进程，立刻从监控或日志定位并终止：

• 在Presto CLI或JDBC连接中执行：SELECT query_id, user, state, query FROM system.runtime.queries WHERE query LIKE '%CROSS JOIN%' AND state = 'RUNNING'
• 确认后立即终止：CANCEL QUERY '<code>query_id'（注意不是pg_terminate_backend，那是PostgreSQL的）
• 若已OOM，检查jvm.config中是否启用了-XX:+HeapDumpOnOutOfMemoryError，结合heap-headroom-per-node预留缓冲（建议设为Xmx的15%~20%，如-Xmx40G则配memory.heap-headroom-per-node=8GB）

真正难的不是写对SQL，而是意识到：Presto里没有“先跑起来再优化”的余地。CROSS JOIN一旦进生产，往往不是某条语句挂掉，而是整个Worker节点因内存耗尽被驱逐，引发雪崩。每次提交前，必须用EXPLAIN看OutputRowCount是否在千行级以内——这是唯一靠谱的防线。