分库分表之后，跨片 JOIN 和聚合查询到底该谁来扛？

背景

做了 10 年大数据平台，最近半年在两个团队里反复撞到一个"分完之后才暴露"的坑：分库分表把单表 80GB 拆到了 16 个分片，单片查询 P99 从 120ms 降到 8ms，看起来很完美；结果第二天报表团队来找——"用户维度的 GMV 汇总跑不动了"。因为分片键是 order_id，而报表要按 merchant_id 聚合，一次查询要扇出到 16 个分片，中间件层做跨片 JOIN 和二次聚合，P99 直接飙到 8s，偶尔 20s 超时。

社区里已经有人讨论过"什么时候该分库分表"（id=196）和"该不该先上分区"（id=79），但分完之后查询侧怎么扛这个话题我还没看到有人系统聊过。今天想抛出来。

常见分歧（我碰到的四种做法）

1. 中间件硬扛派：ShardingSphere / MyCat 配好路由规则，跨片 JOIN 让中间件做归并。优点是业务无感；缺点是跨片 JOIN 本质是 N 次网络 RTT + 内存归并，分片越多越慢，而且中间件的执行计划基本是"先全量拉回再 JOIN"，优化空间有限。我实测过 16 片 × 每片 50 万行的跨片 JOIN，P99 稳定在 5-8s。

2. 冗余宽表派：在写入侧把需要跨片关联的字段冗余到每张分片表里（比如 t_order 里冗余 merchant_name、category_id）。优点是查询变成单片操作；缺点是写入放大、字段冗余导致数据不一致风险，而且"哪些字段该冗余"的判断在业务迭代中会不断漂移。

3. 二次聚合派：对于 COUNT/SUM/MIN/MAX 这类可加函数，先各分片本地聚合，再在应用层汇总。优点是网络传输量从 N×rows 降到 N×1；缺点是只适用于可加函数，AVG 要拆成 SUM/COUNT，DISTINCT COUNT 基本没法拆，而且应用层逻辑复杂度高。

4. 异步物化 / 数据仓库派：核心交易链路走分片表做单片操作，所有跨片聚合、报表、分析查询走离线（T+1）或准实时（Flink CDC → Doris/ClickHouse）物化层，绝不让在线中间件做跨片 JOIN。优点是查询性能稳定、在线链路干净；缺点是数据延迟（T+1 或分钟级）、多一套 ETL 链路要维护、业务方要接受"实时"和"准实时"的语义差异。

我的倾向

我目前偏向 4 为主 + 3 为辅 的组合，核心原则是：在线链路只做单片操作，跨片聚合一律下沉到离线/准实时层。具体：

• 核心交易查询（按 order_id 查单、按 merchant_id 查近期订单）→ 单片路由，P99 < 50ms，这是分库分表的"本分"；
• 可加聚合的轻量场景（比如"今日某商户订单数"）→ 二次聚合，各分片本地 COUNT 再 SUM，网络开销可控；
• 报表、BI、用户画像、跨商户对比 → 走 Flink CDC 实时同步到 Doris，Doris 的 MPP 引擎天然适合这类扫描型聚合，延迟控制在 1-3 分钟；
• 绝不在在线链路里做跨片 JOIN——这是我从两个团队踩坑后最坚定的结论。

理由：分库分表的本质是用空间换单片性能，它的代价是牺牲了跨片关联的便利性。如果你把跨片 JOIN 的查询也塞进在线链路，等于把分库分表省下来的性能又还回去了，还多了一层中间件的复杂度。跨片聚合是"分析型"负载，应该走分析型引擎，而不是让 OLTP 中间件兼职 OLAP。

想听大家聊聊

1. 你们分库分表之后，跨片查询（JOIN / 聚合 / 报表）最终走的是哪条路？中间件硬扛、冗余宽表、二次聚合、还是异步物化？各在你什么场景下翻过车？
2. 如果业务方坚持"我要在分片表上实时查跨商户汇总"，你最后怎么妥协的？有没有"看起来能扛但半年后翻车"的案例？
3. 二次聚合的边界你们怎么划的？可加函数好说，DISTINCT COUNT、百分位数、Top-N 这类不可拆的聚合，你们是在线算还是离线算？
4. 有没有人试过 TiDB / OceanBase 这类分布式数据库来"绕开"分库分表？实际体验如何？是真的"不用分"还是"换了个方式分"？

欢迎贴具体的分片数、单片行数、跨片查询的 P99 数字，数字比形容词有说服力。