ClickHouse Join 优化：大表硬连大表，通常没有好下场

ClickHouse 擅长分析扫描，但不代表可以随意大表 join 大表。很多查询慢在 join：右表过大、join key 基数高、分布式表数据倾斜、内存爆掉、临时数据溢出。分析系统不是不能 join，而是要知道 join 的代价。

ClickHouse Join 优化的第一原则：能提前缩小数据，就不要把大表原样推到 join 阶段。

一、先看 Join 形态

flowchart TD A[Fact Table] --> C[Join] B[Dimension Table] --> C C --> D[Aggregation] D --> E[Result]

事实表 join 小维表是常见模式，通常可控。大事实表 join 大事实表，就要非常谨慎。

二、右表大小很关键

ClickHouse 很多 join 策略会把右表构建成 hash table。右表过大，内存压力就上来。

SELECT * FROM events e ANY LEFT JOIN users u ON e.user_id = u.user_id WHERE e.event_date = today();

如果只需要右表部分列，就不要SELECT *。列越多，构建和传输成本越高。

三、先过滤再 Join

把过滤条件尽量推到 join 之前。

WITH filtered_events AS ( SELECT user_id, event_type, ts FROM events WHERE event_date = today() ) SELECT * FROM filtered_events e LEFT JOIN users u ON e.user_id = u.user_id;

如果过滤条件写得不清楚，优化器未必能替你做最优选择。别把所有希望寄托在自动优化上。

四、必要时用字典或预聚合

小维表高频关联，可以考虑 ClickHouse Dictionary。固定报表场景，可以预聚合或物化视图。

SELECT user_id, dictGetString('user_dict', 'city', user_id) AS city FROM events;

字典不是万能，但能避免某些高频维表 join。预聚合则适合重复查询固定指标。

分布式表还要注意数据分布。如果 join key 和分片 key 不一致，查询可能触发跨节点数据交换。单机测试很快，不代表分布式环境也快。

join_checklist: right_table_size join_key_cardinality shard_key_alignment selected_columns memory_limit

上线前最好用接近生产的数据分布压测。ClickHouse 很多性能问题不是 SQL 写法本身，而是数据在集群里分得不均匀。

五、总结

ClickHouse Join 优化要关注 join 形态、右表大小、过滤下推、列裁剪和数据倾斜。大表硬连大表，通常没有好下场。

分析系统的性能来自数据组织和查询形态。Join 可以用，但要让它处理尽可能少、尽可能窄、尽可能均匀的数据。

如果一个查询每次都需要大表互相洗牌，通常应该重新审视明细表、宽表、字典或物化视图的设计。

查询优化的尽头经常不是改 SQL，而是把数据提前组织到更适合读取的形态里。

这比在错误形态上继续微调更可靠。

数据形态对了，执行器才有发挥空间。