ClickHouse中argMax窗口函数单线程运行缓慢问题求助

我执行以下查询语句：

SELECT argMax(IFNULL(A, 0), B) over (partition by C)
FROM db.table
WHERE B between 0 AND 10000000;

遇到两个问题：

• 仅使用单个线程运行（集群含4个分片，为Distributed源表，具备多CPU，max_threads=0）
• 查询运行极慢，耗时达数分钟

附加信息 #

列类型 #

A - int32
B - int32
C - int32

EXPLAIN PIPELINE结果 #

(Expression)
ExpressionTransform
  (Window)
  WindowTransform
    (Sorting)
    MergingSortedTransform 19 → 1
      MergeSortingTransform × 19
        LimitsCheckingTransform × 19
          PartialSortingTransform × 19
            (Union)
              (Expression)
              ExpressionTransform × 16
                (ReadFromMergeTree)
                MergeTreeThread × 16 0 → 1
              (ReadFromRemote)

表设置 #

• 分布式表：ENGINE = Distributed(table_loc, sharding_key=C)
• 本地表table_loc：ENGINE = MergeTree ORDER BY B SETTINGS index_granularity = 8192

解决方法 #

1. 重构查询，避免全局单线程窗口计算 #

从执行计划能看到，MergingSortedTransform把多流合并成1路后，后续窗口计算只能单线程运行。由于分片键就是C，可以让每个分片先在本地完成分组计算，再汇总结果：

• 如果不需要保留原表每行数据，直接用分组查询替代窗口函数：

SELECT C, argMax(IFNULL(A, 0), B)
FROM db.table
WHERE B between 0 AND 10000000
GROUP BY C;

• 如果需要保留原表每行数据，先预计算每个C的结果再关联：

SELECT t.*, agg.arg_max_val
FROM db.table t
JOIN (
    SELECT C, argMax(IFNULL(A, 0), B) AS arg_max_val
    FROM db.table
    WHERE B between 0 AND 10000000
    GROUP BY C
) agg ON t.C = agg.C
WHERE t.B between 0 AND 10000000;

这样每个分片能并行处理自己的数据，彻底规避全局单线程瓶颈。

2. 调整本地表排序键，减少排序开销 #

本地表当前按B排序，窗口按C分区时需要重新排序。把排序键改成(C, B)，这样每个C分区内的数据天然按B有序，计算argMax时无需额外排序：

ALTER TABLE table_loc MODIFY ORDER BY (C, B);

这个改动能大幅降低计算阶段的资源消耗，同时让分片内的并行计算效率更高。

3. 调整窗口线程数参数（辅助优化） #

如果必须保留窗口函数写法，可尝试设置max_window_threads允许窗口计算多线程执行：

SET max_window_threads = 8; -- 根据实际CPU核心数调整

注意这个参数的效果依赖于窗口函数实现，优先推荐前两种从根本上优化的方案。

内容的提问来源于stack exchange，提问作者techkuz