一条 P50 800ms / P99 15s 的分析查询，到底是「重写 + 索引」还是上物化视图？你的团队用什么判据来决定，而不是拍脑袋？

【背景】 先说结论倾向：多数情况下，先重写查询、把物化视图当最后手段；但真正难的从来不是技术选型，而是缺少一个「可复用的判据」，最后都退化成架构师拍脑袋。

我最近处理的一条典型 case：一张 2.4 亿行的订单明细表（InnoDB，按 create_time 分区），一个运营报表接口 SELECT ... GROUP BY sku, city 带 30 天滚动窗口，P50 约 800ms，P99 能到 15s，且 P99 尖刺往往出现在凌晨大批量补数 / 分区维护之后。两条路摆在那：

• A：重写查询（先按时间分区裁剪、把 GROUP BY 下推到子查询、必要时加覆盖索引或汇总表），代价是一次性的查询工程 + 后续维护；
• B：上物化视图 / 预聚合表（MySQL 里就是定时物化 + 增量合并），读侧 P99 直接进 50ms，代价是新鲜度窗口、双写一致性、回刷口径漂移。

【常见的几种做法 / 分歧】

1. 「能改查询就改查询」派：认为物化视图是把查询复杂度高了成本、一致性成本外移到调度与对账上，是「把问题搬家不是消除」。
2. 「超过 1s 就该物化」派：读路径上任何秒级延迟都是事故隐患，物化视图换来的是确定性，确定性比「理论上可以更快」值钱。
3. 「看数据规模」派：行数 < 5000 万重写，> 1 亿直接物化——我听过这个说法，但没听过任何一家敢把行数写成硬阈值。
4. 「看 P99 波动源」派：如果 P99 尖刺来自写侧（补数、DDL、分区操作）而不是查询本身，那重写查询治标不治本，该做的是错峰 + 物化。

【我的倾向与理由】 我倾向用三个可量化的信号来判，而不是拍：

1. P99 / P50 的比值：> 10 倍说明尖刺来自数据分布或写侧扰动，重写查询收益有限，优先物化或预聚合；< 3 倍说明查询本身可优化，重写优先。
2. 新鲜度容忍度：业务能接受 5min 延迟就物化，要求秒级就老老实实重写 + 索引，物化在这个场景反而是降级。
3. 回刷频率：如果口径每月改 1 次以上，物化视图的维护成本会指数级上升，此时重写查询 + 查询层抽象（SQL 模板）更抗变化。

但我不确定这个判据在「写密集 + 口径稳定」和「读密集 + 口径漂移」两个极端下是否还成立，想听大家实际怎么用的。

【想听大家聊的】

• 你们团队有没有一个「查询 vs 物化」的决策清单或阈值？还是每次都 case by case？
• 物化视图回刷窗口内，读侧到底走「旧数据 + 标记」还是「阻塞等待」？你们的 SLO 怎么记？
• 有没有遇到过「物化视图上线后 P99 反而变差」的反直觉 case？根因是什么？
• 对 InnoDB 场景，大家是定时物化 + 增量 merge，还是直接用 ClickHouse / StarRocks 这类列存引擎承接？迁移的触发条件是什么？