你在项目里对 ClickHouse 做过哪些真实优化？最好结合数据量和优化前后指标说明。
我的判断
真实优化要用扫描量、Part 数、写入批次和并发指标证明；我会优先修表模型和数据链路，再调参数。
一次订单明细项目里，单条 Kafka 消息就写一次 ClickHouse，产生大量小 Part，merge 长期追不上，查询从 2 秒抖到十几秒。我们把消费端改成按分区聚合，达到约 5~10 万行或一秒就批量写，active parts 和 merge IO 明显下降。
随后按 Top 查询把 ORDER BY 从单纯时间改成 (tenant_id, event_date, user_id, event_time)，并限制报表必须带租户和时间。常用日报做物化聚合，接口不再每次扫原始明细。
我会用这组前后指标说明结果，而不是只说“快了”：
- 单批行数、每分钟新 Part 和 active parts；
- 每个查询的 read_rows/read_bytes；
- P95/P99、峰值内存和磁盘吞吐；
- 合并积压以及写入端到可查询的延迟。
任何数字都必须来自同一数据量和并发条件。把查询从 40 秒测到 3 秒但换了时间范围，没有意义。