GLOBAL JOIN会广播右表到所有节点，易引发内存爆炸；应优先用ANY JOIN+预过滤、字典表或冗余字段替代。
GLOBAL JOIN 会广播右表到所有节点，容易爆内存
ClickHouse 的 GLOBAL JOIN 不是简单地把右表查一次再分发，而是会在每个参与查询的分片节点上，**各自执行一次右表子查询**，然后把结果全量广播给所有左表所在节点。如果右表本身是分布式表（比如 distributed_users），那这个子查询会再次触发全集群扫描 —— 出现“N×N”级放大，极易触发 Memory limit (for query) exceeded 或 Timeout exceeded while receiving data from remote server。
常见错误现象：
- 单次查询占用数百 GB 内存，Coordinator 节点 OOM
- 查询耗时从毫秒级飙升到分钟级，且 CPU 持续 100%
- 日志里反复出现
Cannot allocate memory for join或Too many simultaneous queries
实操建议：
- 先确认右表是否真需要
GLOBAL：如果右表是本地小表（MergeTree引擎、数据量 JOIN 即可，无需加GLOBAL - 若右表必须跨集群拉取，优先改用字典表（
CREATE DICTIONARY）+dictGet，避免每次查询都重跑子查询 - 强制限制右表数据量：在子查询中加
LIMIT或WHERE过滤（例如只取最近 30 天活跃用户），但注意GLOBAL IN/GLOBAL JOIN中的子查询不支持LIMIT直接生效，需包裹进子视图或物化视图
用字典表替代 GLOBAL JOIN 是最稳妥的降级方案
字典表本质是将右表数据加载为内存驻留结构，由 ClickHouse 主动管理生命周期（通过 LIFETIME 配置自动刷新），查询时仅做哈希查找，完全规避网络广播和重复计算。
使用场景：
- 右表数据量稳定（
- JOIN 键为高基数等值匹配（如
user_id,device_id） - 无法修改表结构，又想绕过
GLOBAL JOIN的 N² 放大问题
关键参数差异：
-
SOURCE(CLICKHOUSE(TABLE 'users'))：指定源表，注意该表必须是本地表（非Distributed），否则字典构建失败 -
LIFETIME(MIN 300 MAX 3600)：建议设成 5~60 分钟，太短导致频繁 reload，太长导致数据陈旧；生产环境避免用MIN 0 -
LAYOUT(HASHED())：适用于等值查询；若需范围查找，改用COMPLEX_KEY_HASHED并声明复合键
示例：
CREATE DICTIONARY user_profile_dict
(
`user_id` UInt64,
`region` String,
`vip_level` UInt8
)
PRIMARY KEY user_id
SOURCE(CLICKHOUSE(TABLE 'users_local'))
LIFETIME(MIN 600 MAX 3600)
LAYOUT(HASHED());后续查询直接用：dictGet('user_profile_dict', 'region', toUInt64(user_id))，无广播、无子查询、毫秒响应。
实在要用 GLOBAL JOIN，必须控制右表子查询的数据规模
很多人以为加了 GLOBAL 就能“一劳永逸”，其实它只是把问题从 Coordinator 转移到了每个 Worker 节点 —— 如果右表子查询本身慢或大，所有节点都在重复干同一件事。
性能瓶颈往往卡在右表子查询上，而不是 JOIN 本身。所以优化重心要前置：
- 确保右表子查询走主键或跳数索引：例如
SELECT id, name FROM users WHERE update_time >= today() - 7，必须让update_time在ORDER BY或有MINMAX索引 - 禁用
GLOBAL JOIN的隐式全量扫描：显式指定右表为本地表别名，例如GLOBAL JOIN users_local AS u ON ...，而非GLOBAL JOIN users_distributed - 调大临时资源上限（仅限临时救急）：
SETTINGS max_memory_usage = 20000000000, max_bytes_before_external_group_by = 10000000000，但治标不治本
一个容易被忽略的细节：GLOBAL JOIN 的右表子查询默认不继承外层查询的 max_threads，它会按节点最大线程数跑满 —— 若集群节点配置不均，可能某台低配节点率先超时。建议显式加 SETTINGS max_threads = 4 到子查询中。
ANY JOIN + 分布式表预过滤比 GLOBAL JOIN 更可控
当业务允许“只取第一个匹配值”（比如用户最新归属区域、设备最后一次上报型号），ANY LEFT JOIN 配合右表预过滤，比 GLOBAL JOIN 更轻量、更可预测。
原理差异：
-
GLOBAL JOIN：右表全量广播 → 每个左表分片都收到完整右表 → 内存压力随分片数线性增长 -
ANY LEFT JOIN（无 GLOBAL）：右表按 Join 键分片路由 → 左表分片只和对应右表分片通信 → 数据本地性保留
实操要点：
- 右表必须和左表用相同分片键（如都按
cityHash64(user_id)分片），否则仍会退化为广播 - 右表子查询务必加过滤条件，例如：
SELECT user_id, region FROM users_local WHERE region != ''，避免空值拖慢哈希构建 - 显式指定算法：
SETTINGS join_algorithm = 'hash'，防止 ClickHouse 自动切到低效的partial_merge
典型写法：
SELECT e.*, u.region
FROM events_local AS e
ANY LEFT JOIN (
SELECT user_id, region
FROM users_local
WHERE region IN ('CN', 'US', 'JP')
) AS u USING (user_id)
SETTINGS join_algorithm = 'hash';这种写法不会触发全局广播，资源消耗与分片数无关，只要右表过滤后数据量可控（百万级以内），就能稳住 P99 延迟。
真正难的不是写出 GLOBAL JOIN，而是判断它是不是唯一解。绝大多数场景下，字典表、预聚合、冗余字段这三招，比硬扛 GLOBAL JOIN 更省心、更稳定。一旦发现查询里出现 GLOBAL 关键字，第一反应不该是调参，而是问一句：这个右表，能不能提前固化？
