你们用 ClickHouse 存什么数据？MergeTree 表引擎为什么适合这个场景？
我的判断
我们用 ClickHouse 保存追加型明细和聚合分析，MergeTree 通过列式存储、排序数据段和后台合并适合大扫描，不拿它做高频事务更新。
典型是订单事件、用户行为和调用日志：每天持续追加，查询按租户、时间和业务维度聚合。MySQL 做这类多列扫描和聚合会影响在线事务，ClickHouse 只读取涉及的列，并利用向量化批量计算，单位硬件吞吐更高。
MergeTree 写入后形成不可变 Part，Part 内按 ORDER BY 排序并建立稀疏索引；后台把小 Part 合并成大 Part。查询如果带排序键前缀和分区条件，可以跳过大量数据块。
我们不会把订单主状态只放 ClickHouse。它不适合逐行事务、频繁小更新和强一致点查；数据通常从 Kafka/binlog 异步进入，允许分钟或秒级延迟，权威值仍在 OLTP。
上线会看写入批次、active parts、合并积压、扫描行数/字节和查询延迟。MergeTree 的优势建立在合理分区、排序键和批量写入上，不是换引擎名就会变快。