Shuffle 是聚合慢的根源，而非数据量大本身；其本质是跨节点重分发数据导致网络、序列化等开销远超计算，本地聚合和物化中间结果可有效缓解。
Shuffle 是聚合慢的根源，不是数据量大本身
分布式数据库里执行 SUM、COUNT、GROUP BY 时，真正拖慢查询的往往不是计算，而是跨节点的数据重分发（即 Shuffle）。数据库必须把相同分组键（如 user_id）的行全部归集到同一个节点上，才能完成最终聚合。这个过程涉及网络传输、序列化、反序列化、临时存储，开销远高于单机内存累加。
常见错误现象：
- 查询耗时陡增，且 CPU 利用率不高，但网络 IO 和磁盘 IO 持续打满
-
EXPLAIN显示执行计划中存在Exchange或Redistribute节点 - 相同 SQL 在单机 MySQL 上毫秒级，在 OceanBase 或 TiDB 上变成秒级甚至分钟级
本地聚合（Partial Aggregate）能省掉多少 Shuffle？
现代分布式数据库（如 PostgreSQL 14+、TiDB 7.0、OceanBase 4.3）都支持两阶段聚合：先在每个节点上做 Partial SUM、Partial COUNT，再把中间结果发给一个汇总节点做 Final SUM。这能大幅减少网络传输量——比如 100 万行按 region 分组，原始 Shuffle 数据量可能是 100MB；启用本地聚合后，可能只剩 1KB 的中间状态（如 {'华东': 2456789, '华北': 1834201}）。
关键控制点：
- 确认是否启用：检查执行计划中是否有
PartialAggregate或LocalHashAggregate节点 - 某些场景会自动禁用：如
GROUP BY字段未建索引、聚合函数含DISTINCT、或用了不支持下推的窗口函数 - MySQL 兼容模式下（如 OB MySQL 模式），
sql_mode含ONLY_FULL_GROUP_BY可能抑制优化器选择局部聚合路径
为什么 GROUP BY 字段没索引，本地聚合也救不了你
本地聚合的前提是：每个节点能独立识别“哪些行属于同一分组”。如果 GROUP BY 字段没有本地索引（或分区键不匹配），节点就无法提前按分组切分数据，只能把全量原始行发出去，Shuffle 量回归原始规模。
典型陷阱：
- 表按
order_id分区，却对user_id做GROUP BY→ 每个节点都得把所有user_id行发给其他节点 - 聚合字段是表达式，如
GROUP BY DATE(created_at)→ 即使created_at有索引，表达式也会导致本地无法预分组 - 使用了
COLLATE utf8mb4_unicode_ci等非二进制排序规则 → 节点间比较逻辑不一致，强制回退到全局 Shuffle
物化中间结果比硬扛 Shuffle 更实际
当业务要求高频响应（如报表每 5 分钟刷一次），与其反复触发跨节点 Shuffle，不如把聚合结果固化下来。这不是妥协，而是分布式环境下更可控的选择。
实操建议：
- 用定时任务写入汇总表：
INSERT INTO daily_user_order_sum SELECT user_id, COUNT(*), SUM(amount) FROM orders WHERE order_time >= '2026-04-24' GROUP BY user_id - 避免用
ON DUPLICATE KEY UPDATE或MERGE实时更新——它们仍需先读再判重，可能引发热点 - 若用物化视图（如 PostgreSQL 的
MATERIALIZED VIEW或 OB 的REFRESH FAST ON COMMIT），注意其刷新机制是否真正异步且不阻塞查询
最易被忽略的一点：Shuffle 不是“能不能避免”的问题，而是“在哪一层规避”更合理。应用层预聚合、物化层缓存、SQL 层提示（如 /*+ AGG_STRATEGY(LOCAL)）三者要结合具体负载选型，而不是默认指望数据库自动最优。
