GLOBAL JOIN能减少跨节点数据传输，是因为它先在协调节点执行右表查询并构建全局临时表，再将该表广播至所有分片，避免了分布式环境下每个分片重复查询右表导致的O(N²)查询放大问题。
为什么GLOBAL JOIN能减少跨节点数据传输
ClickHouse的分布式JOIN默认走DISTRIBUTED JOIN，即把右表按Join键哈希分发到各节点，再与本地左表匹配。当右表小（GLOBAL JOIN会先在coordinator节点拉取右表全量数据，广播到所有worker节点内存中，让每个节点用本地左表直接匹配——彻底规避了右表分发阶段的网络传输。
GLOBAL JOIN的正确写法和触发条件
必须显式写GLOBAL INNER JOIN或GLOBAL LEFT JOIN，不能只写JOIN加GLOBAL提示；右表必须是单机表或Distributed表但实际数据可被coordinator一次性读完（否则会报错Too large result of GLOBAL subquery）。
- ✅ 正确：
SELECT * FROM dist_table GLOBAL INNER JOIN users ON dist_table.user_id = users.id - ❌ 错误：
SELECT * FROM dist_table INNER JOIN users ON dist_table.user_id = users.id SETTINGS distributed_product_mode = 'global'（该设置仅影响IN，不生效于JOIN） - ⚠️ 注意：
users表若本身是Distributed引擎，需确保其底层分片数少、单分片数据量小，否则coordinator拉取失败
GLOBAL JOIN的内存与超时风险
右表数据会被完整加载进每个worker节点的内存，若未限制大小，极易触发Memory limit (for query) exceeded。必须配合max_bytes_before_external_group_by和max_memory_usage使用，并预估右表广播后占用内存（通常为原始大小×2~3倍）。
- 强制限制右表体积：
SELECT * FROM dist_table GLOBAL INNER JOIN (SELECT * FROM users LIMIT 100000) AS users ON ... - 调高单节点内存上限：
SET max_memory_usage = 8000000000（8GB） - 启用外部聚合降内存压力：
SET max_bytes_before_external_group_by = 2000000000
替代方案：什么时候该换ANY JOIN或本地JOIN
GLOBAL JOIN不是万能解药。当右表存在重复id且你只需任一匹配行时，GLOBAL ANY JOIN更轻量；当左右表都建在相同分片键上（如都按user_id分片），直接用普通INNER JOIN就能触发本地JOIN，完全不需要网络传输——这时硬上GLOBAL反而浪费资源。
- 右表键唯一 → 优先
GLOBAL INNER JOIN - 右表键可能重复，且业务接受任意一条 → 改用
GLOBAL ANY JOIN - 左右表
Distributed表共用同一分片键 → 删除GLOBAL，用原生JOIN，靠ClickHouse自动路由到本地执行
真正卡住性能的往往不是语法写错，而是没确认右表在coordinator上能否被完整读出，以及忘了给每个worker节点同步调大内存限制。
