clickhouse分布式表不支持窗口函数，因其distributed引擎仅下发查询至各分片独立执行，无法实现跨分片全局排序与行序协调，导致row_number等结果错乱；窗口函数仅适用于单节点本地表。
OVER 子句在分布式表上不生效，根本原因是 ClickHouse 的分布式引擎不支持跨分片的窗口计算。
ClickHouse 的 Distributed 表本身不存数据，只是把查询下发到各个本地分片（ReplicatedMergeTree 表），然后合并结果。而窗口函数（如 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)）要求**全量有序数据参与计算**——这在分片独立执行、无全局排序协调的前提下不可能完成。
常见错误现象包括：
- 查询不报错但结果错乱：比如
ROW_NUMBER()在每个分片上各自从 1 开始编号，最终合并后出现大量重复序号 - 使用
RANGE或ROWS BETWEEN时返回空或部分结果，因为各分片无法感知其他分片的行边界 -
LAG()/LEAD()返回 NULL 偏多，实际是因相邻行落在不同分片上，本地分片查不到“隔壁”的值
必须先在本地表上跑窗口逻辑
窗口函数只能安全用于单节点上的本地表（如 ReplicatedMergeTree）。若原始数据已按分片键分布，且业务能接受「按分片内局部窗口」语义，可强制路由到某一分片执行：
- 用
SELECT ... FROM remote('host:port', db, table) WHERE ...指定单个节点查本地表 - 或加
SETTINGS distributed_group_by_no_merge = 1防止结果合并（但仅适用于 GROUP BY 场景，对窗口无效） - 更稳妥的做法：先用
Distributed表做聚合/过滤，把中间结果写入一张临时本地表，再在其上跑窗口函数
替代方案：用 ARRAY JOIN + arrayEnumerate 粗粒度模拟
如果只是需要“组内编号”这类简单需求，且数据量可控，可用以下技巧绕过：
SELECT user_id, event_time, arrayJoin(arrayEnumerate(groupArray(event_time))) AS row_num FROM ( SELECT user_id, groupArray(event_time) AS events FROM default.distributed_events GROUP BY user_id ) ARRAY JOIN events, row_num
注意：groupArray 有内存限制，默认 10MB，超限会截断；且不能保证 events 严格按时间排序，需显式 ORDER BY event_time 再 groupArray。
为什么不能靠集群配置修复？
这不是配置遗漏或版本 bug，而是架构层面的约束：
-
Distributed引擎不提供跨分片事务、全局排序或行级协调能力 - ZooKeeper 只管元数据和副本同步，不参与 SQL 执行调度
- 即使启用
parallel_replicas或distributed_product_mode = 'local'，也只是影响读取路径，不改变窗口函数的执行域
真正要跨分片做窗口计算，得把数据拉到一个节点上（比如用 remote 函数集中读取），但这会失去分布式优势，还可能压垮单点。所以设计阶段就得明确：窗口逻辑属于「查询侧后处理」，不适合放在分布式入口层。
