clickhouse的一些优化建议和工具
内容提要
作者用 cloki 和 ClickHouse 替代日志系统时遇到查询慢与写入问题。查询慢源于大表 left join 和排序，通过让 ORDER BY 与表一致、缩短 TTL、调整分区，将查询降至 10 秒内，并建议调优 max_threads、内存及外部排序参数。大量单条插入导致 merge 跟不上、表只读，Buffer 表效果有限，最终改用 clickhouse-bulk 批量写入并缓存失败数据，系统逐渐稳定。
延伸解读
查询优化：对齐排序键与缩短TTL
作者发现大表left join导致查询缓慢，通过将表的ORDER BY与查询的ORDER BY对齐（改为ORDER BY (fingerprint, labels)），并缩短time_series_dist表的TTL至1天，显著降低了排序时间和内存占用，使查询降至10秒内。这说明在ClickHouse中，让排序键匹配高频查询模式能有效减少最终排序开销，而合理控制数据生命周期可缩小参与join的表体积。
分区键选择：避免过度分区
作者曾尝试将PARTITION BY date改为PARTITION BY fingerprint以加速查询，但导致每个fingerprint一个分区，集群报错“Too many parts”。这提醒读者，分区键应选择低基数且与查询过滤条件匹配的列（如日期），盲目用高基数列分区会引发元数据膨胀和写入失败。若需更细粒度，可考虑将分区时间改为半天，而非改用高基数列。
写入瓶颈：批量插入与缓冲工具
大量单条插入导致merge速度跟不上，触发只读保护并丢失日志。Buffer表效果有限，作者最终采用clickhouse-bulk将小插入聚合成大插入，并配置flush_count、flush_interval等参数，失败时生成dump文件重试。这表明ClickHouse更适合批量写入，面对高频单条插入场景，应引入外部缓冲工具，而非依赖内置Buffer表。
参数调优：内存与线程的平衡
作者建议调整users.xml中的参数：max_threads不宜过高以免内存占用过大；max_memory_usage可设为内存的90%；max_bytes_before_external_group_by和max_bytes_before_external_sort设为max_memory_usage的一半，以便超限时落盘。这些调整有助于在查询性能与内存安全间取得平衡，但需注意落盘会牺牲部分效率。
Q&A
ClickHouse查询慢，left join大表导致内存占用高，有什么优化方法？
让表的ORDER BY与查询的ORDER BY一致，减少排序时间；将left join后的大表TTL改短（如1天）以减小表大小；调整max_threads、max_memory_usage等参数，并设置max_bytes_before_external_sort和max_bytes_before_external_group_by让排序和分组溢出到磁盘。
ClickHouse中PARTITION BY使用fingerprint有什么问题？
PARTITION BY fingerprint会导致每个数据一个分区，产生过多分区（Too many parts错误），应使用日期分区（如PARTITION BY date），跨天查询快，也可将分区时间改为半天。
ClickHouse大量单条插入导致表只读、merge跟不上，如何解决？
ClickHouse适合一次性插入大量数据，不适合短时间大量单条插入。可用Buffer表缓冲，但官方不推荐；更有效的是使用clickhouse-bulk工具，将小插入缓存后批量写入，并配置dump文件重试失败数据。
clickhouse-bulk的配置参数中flush_count和flush_interval分别是什么意思？
flush_count是缓存多少行后写入ClickHouse（如100万行），flush_interval是缓存多少秒后写入（如5秒），两者满足其一即触发写入。
ClickHouse的users.xml中max_threads参数应该如何设置？
max_threads不要设置太高，一般使用默认值即可，线程越高内存占用越大，并非越高越好。
ClickHouse中distributed_product_mode参数在分布式表下应该怎么设置？
对于ReplicatedReplacingMergeTree+Distributed的分布式表，一定要设置为global；如果只是MergeTree+Distributed可以设置为local。
