物化视图

【背景】 热榜上连接池 P99、超时重试、Kafka 位点这些话题，根子往往都落在同一件事上：读路径里到底让数据库在查询时做计算（实时 JOIN / 聚合），还是把结果提前算好、查询时只做取数（宽表 / 物化 / 预聚合）。我做了 10 年

【背景】 先说结论倾向：多数情况下，先重写查询、把物化视图当最后手段；但真正难的从来不是技术选型，而是缺少一个「可复用的判据」，最后都退化成架构师拍脑袋。 我最近处理的一条典型 case：一张 2.4 亿行的订单明细表（InnoDB，按 c

背景 我做了 15 年数据管道，目前维护一个 ClickHouse 集群（2 shard × 2 replica，单机 64C/256G），上面同时跑两类负载： 1. 在线交互查询：运营看板 + 自助 SQL，QPS 不高（峰值约 80 Q

【背景】 做了 8 年数据工程，最近半年在帮三个不同团队看 OLAP 链路，发现一个反复出现的"看似简单、其实没人说得清"的取舍： 业务方要一个运营看板，核心指标是「近 1 小时 / 近 24 小时 / 近 7 天」的 PV、UV、GMV、

背景 我做了 10 年大数据平台，最近半年在两个团队里反复撞见同一个"建完之后才暴露"的问题：物化视图、Redis 缓存、StarRocks 物化表都建好了，P99 从 3s 降到 30ms，看起来很完美；结果运营第二天来问"昨天 14:0