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是否在千行级以内——这是唯一靠谱的防线。
