你们项目为什么引入 ClickHouse？它解决了什么问题，又有哪些场景坚决不用？
我的判断
我们引入 ClickHouse 是把大规模明细扫描和聚合从 MySQL 拆走，但交易写入、强一致点查和频繁小更新仍留在 OLTP。
项目里原来的运营报表会扫 MySQL 几千万行，还和下单共享 IO。把订单事件通过 Kafka 同步到 ClickHouse 后，按时间、渠道、地区聚合从几十秒降到秒级，同时不再拖慢主库。列裁剪、压缩和向量化非常适合这种读多、写入追加、允许短暂延迟的场景。
我坚决不用它处理这些事情：
- 余额扣减、订单状态机等多行事务；
- 每次只按主键查一行且要求立即读到最新值；
- 高频逐行更新、删除；
- 高并发短查询且没有接口层并发保护。
引入前还要算完整成本：数据同步与补数、重复与乱序、集群运维、冷热存储、查询治理。MySQL 里一个正确索引就能解决的问题，不值得为此引入 ClickHouse。