分析查询和在线交易抢同一个库，你们到底怎么拆的？

【背景】 我这两年在大厂数据平台组，一个反复出现的场景：业务方既要在线交易（下单、查订单详情，P99 要求 50ms 内），又要跑分析型查询（按商户/时间维度聚合上千万行流水、环比同比、导出报表）。很多时候这两类查询落在同一个 MySQL 上——要么直接查主库，要么走同一套主从。结果就是：在线接口 P50 很稳，但一到大促或者有人跑了个重聚合，P99 立刻抖，慢日志里清一色 "SELECT ... GROUP BY merchant_id" 这种大扫描。

【常见分歧 / 几种做法】

1. 读写分离，读流量丢从库，主库只写——最省事，但分析查询本质是"读"，照样把从库打挂，而且主从延迟会让"写后读"不一致。
2. 直接加资源（升配、加从库、加索引）+ 限流 + 慢查询治理——短期能扛，治标不治本，成本线性涨。
3. 走 CDC（Canal/Debezium）把流水同步到独立分析库（ClickHouse / Doris / StarRocks），分析查询全去那边——架构最干净，但多一套同步链路要维护，实时性有秒级延迟，团队还得会运维 OLAP 引擎。
4. 预计算 / 物化视图 / 缓存聚合结果到 Redis，在线只读结果——对高频固定报表很有效，但维度一变就失效，组合爆炸。

【我的倾向与理由】 结论先行：先判断"这个分析查询到底是不是在线路径的一部分"。如果是用户点一下就要出结果的轻聚合（比如订单列表里商户维度的小聚合），我会先做索引 + 缓存 + 限流，别急着上 OLAP；只有当它变成"大数据量、多维度、低频但重"的准实时/离线报表时，才值得引入 CDC + 独立分析库。理由：分析库的边际成本（同步链路、运维、延迟一致性）不低，用在线的简单手段能解决的就别引入复杂度。

【想听大家】 你们在"在线 + 分析"混跑的场景下，是怎么选边界的？具体在什么量级（表行数 / QPS / 聚合维度数）你会拍板"该拆了"？有没有人踩过"上了 ClickHouse 结果同步链路挂了，比不拆还糟"的坑？