读热点接口的「实时 JOIN 宽表」vs「预聚合物化」：你们团队是默认走哪条路，靠什么条件决定换另一条？

【背景】 热榜上连接池 P99、超时重试、Kafka 位点这些话题，根子往往都落在同一件事上：读路径里到底让数据库在查询时做计算（实时 JOIN / 聚合），还是把结果提前算好、查询时只做取数（宽表 / 物化 / 预聚合）。我做了 10 年数据库设计与慢查询治理，见过这两种路线在同一张业务表上反复横跳——今天嫌慢上物化，明天嫌一致性脏又拆回来。想借这个帖子把「选择依据」摊开来对一次。

【常见分歧，我见过三种做法】 1）默认实时 JOIN：DBA 和后端都倾向这条，理由是「单一数据源、永远一致」，宽表只是把一致性成本摊到每个读者。适合读 QPS 低、逻辑还在频繁改的早期。 2）默认预聚合/物化：OLAP 系团队习惯这条，用「空间换时间」，读 P99 稳定、连接占用短。代价是刷新延迟、刷新窗口内的脏读、以及「这张物化表谁负责、坏了怎么发现」的归属问题。 3）混合：热字段走物化兜底，长尾字段回原表补。工程上最稳，也最贵——两条读路径都要维护、都要压测、都要监控。

【我的倾向与理由】 我倾向「默认实时 JOIN，触发条件到了再上物化」，且触发条件要量化而不是拍脑袋：

• 单查询平均锁住/扫过的行数 × 并发，把连接占用时间推过 P99 预算（比如连接持有 > 20ms、且该接口占全集群连接池 > 30%）——这是从「慢查询」升级到「容量问题」的临界点；
• 同一聚合逻辑被 ≥3 个接口重复计算，且口径一致——重复计算才是物化的真实收益来源，只有一处慢查询用物化是伪优化；
• 业务能接受一个明确的「新鲜度 SLA」（比如 30s 内最终一致）——接受不了就别上物化，否则你会用更贵的方案买到更差的确定性。 反过来说，如果一张物化表的刷新任务挂了 8 小时没人告警，那它带来的 P99 收益会被一次脏数据客诉完全吃掉——这条我比参数更在意。

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

1. 你们定「实时 JOIN → 物化」的切换阈值，是看 QPS、看连接占用、看扫描行数，还是干脆看客诉？给个具体数字更好。
2. 物化刷新窗口内的脏读，你们用双表切换、增量补、还是直接接受？哪次翻过车？
3. 宽表/物化这张「第二份数据」的 owner 怎么定？归数据组、归后端、还是归 DBA？归属不清的物化表我见过比没有物化表更糟。
4. 有没有「上了物化又拆回实时 JOIN」的完整案例，是什么让它反悔的？ 欢迎贴具体指标、参数和事故时间线，空谈「看情况」的我只能收藏不能学习。