运营看板的大表聚合查询：现算 vs 预聚合，到底在什么阈值下该切换？

背景

做了 3 年 DBA，治理慢查询时最常撞见的一类场景是：业务方拿着一张几千万甚至上亿行的流水表，让运营看板「实时」出聚合结果（今日 GMV、分渠道转化、库存周转），SQL 写得再漂亮，本质还是在扫大表。而社区里对「该不该预聚合」的立场其实挺分裂的：有人觉得「加索引、写对 SQL 就够了」，有人觉得「凡是 T+1 能算的就不该现算」，还有人直接上物化视图或流式计算。

我想借这个帖把几种常见做法摊开，按场景聊取舍，不聊抽象原则。

常见分歧 / 几种做法

1. 现算派：一条 SQL 扫大表，靠覆盖索引 + 分区裁剪压成本。优点是口径永远一致、无额外存储、无调度依赖；代价是 P99 不可控，高峰期一条看板查询能占掉一个核。
2. 预聚合派（定时任务 + 汇总表）：cron 每 5/15 分钟把增量聚合进 t_summary_5min，看板只查汇总表。优点是查询稳定在毫秒级、主库压力小；代价是数据有延迟、口径漂移风险（增量逻辑和全量逻辑不一致时很难发现）、多一套调度要维护。
3. 物化视图 / 计算引擎派：MySQL 8.0 没有真正的物化视图，所以实践中要么自建「伪物化」（触发器或 binlog 订阅刷新），要么把聚合搬去 ClickHouse / StarRocks / Flink。优点是解耦计算与事务库；代价是架构复杂度上一个台阶，小团队养不起。
4. 混合派：热点维度（今日、Top10）预聚合，长尾维度（任意日期区间 × 任意筛选条件）现算。这个方案看起来最合理，但「哪些维度算热点」基本靠拍。

我的倾向与理由

我倾向 混合派 + 明确的切换阈值，理由有三：

1. 预聚合的本质是「用存储和延迟换查询成本」，它不是免费午餐——每多一张汇总表，就多一份口径维护成本。所以不该无脑上，得有量化判据。
2. 我目前用的经验阈值（欢迎拍砖）：单条聚合扫描行数 > 1000 万、或 P99 > 2s、或同一看板每天被查询 > 100 次，满足任意两条就值得预聚合；否则加覆盖索引 + 分区裁剪就够了。
3. 预聚合一旦上，必须配套「口径校验」——我一般会跑一个每日对账任务，用全量 SQL 和汇总表结果做 diff，偏差 > 0.1% 就告警。没有对账的预聚合，等于埋了一颗口径漂移的雷。

想听大家在什么场景下怎么选

• 你的业务里，预聚合的刷新粒度是 1 分钟、5 分钟还是 15 分钟？延迟和成本的取舍点在哪？
• 汇总表你是用「全量重算」还是「增量累加」？增量方案怎么保证幂等和可重放？
• 有没有遇到过「预聚合上线后口径和现算对不上」的事故？最后怎么定位的？
• 对于「任意日期区间 × 任意筛选条件」这种长尾查询，你们是真的现算，还是干脆不让业务方这么查（改成限定维度组合）？
• 你们团队有没有维护「哪些指标必须现算、哪些可以预聚合」的清单？靠什么流程保证新指标进来时有人做这个判断？

欢迎贴具体的表规模、SQL、刷新策略和踩坑记录，越具体越好。