SQL Sharding 的跨分片聚合与 map-reduce 模式实践

分片聚合需两阶段：分片内局部计算+中央节点全局合并，本质是轻量mapreduce；瓶颈在于无统一分组上下文、内存网络失衡、缺乏容错。

sql 分片（Sharding）后，跨分片的聚合查询（如 count、SUM、GROUP BY）无法直接由单条 SQL 完成，必须协调多个分片结果。这不是语法限制，而是数据物理隔离带来的架构约束。核心思路是：**把聚合任务拆解为“分片内局部计算 + 中央节点全局合并”两阶段，本质就是 mapreduce 的简化落地。**

分片聚合的典型瓶颈在哪

常见误区是把跨分片 select COUNT(*) FROM users 直接发给所有分片，再在应用层累加——这能工作，但容易出错或低效。真正卡点在于：

• 无统一排序/分组上下文：各分片独立执行 GROUP BY city，结果中“北京”可能重复出现多次，无法直接合并
• 内存与网络开销失衡：若某分片返回 10 万行分组结果，而其他分片只返回几十行，中央节点需缓存大量中间数据
• 缺乏容错与超时控制：一个分片响应慢或失败，整个聚合就卡住，传统 JDBC 连接难以优雅降级

MapReduce 模式如何适配分片场景

不必引入 hadoop，用轻量逻辑即可复现 MapReduce 核心思想：

• Map 阶段（分片内）：下发带 GROUP BY 或聚合函数的 SQL 到每个分片，要求结果包含完整分组键（如 city, gender）和局部值（如 COUNT(*) AS local_cnt）。避免只返回标量值
• Shuffle 阶段（合并前）：收集所有分片结果，在内存中按分组键归并。例如分片1返回 {北京, 男, 245}，分片2返回 {北京, 男, 198}，则合并为 {北京, 男, 443}
• Reduce 阶段（全局输出）：对归并后的键值对执行最终计算，如求和、取最大值、平均值（需保留 count+sum 两个字段）

关键细节：分组键必须可哈希且无歧义，推荐用字符串拼接（如 CONCAT(city, '|', gender)）而非依赖数据库 collation。

工程实践中的关键控制点

真实系统中，以下设计决定成败：

• 分片路由与并发粒度：按分片键（如 user_id % 16）并发查询 16 个库，比串行快 10 倍以上；但需限制最大并发数（如 8），防止下游数据库连接打满
• 结果流式合并：不等待全部分片返回再处理，而是边收边归并（用 ConcurrentHashMap 或 TreeMap），降低内存峰值
• 降级策略：允许配置“容忍 N 个分片失败”，失败分片用默认值（如 0）填充，或标记为 partial_result = true 返回给调用方
• 下推计算：尽量让分片完成高成本操作。例如 WHERE create_time > '2024-01-01' 必须下推到分片执行，而非拉全量再过滤

一个可落地的简化示例

统计各城市用户总数（含分片键为 user_id 的 4 个分片）：

-- Map 阶段：并发执行以下 SQL（每分片不同） SELECT city, COUNT(*) AS local_count FROM users  WHERE city IS NOT NULL  GROUP BY city; <p>-- 应用层合并逻辑（伪代码） Map<String, Long> globalCount = new HashMap<>(); for (List<Row> shardResult : allShardResults) { for (Row r : shardResult) { String key = r.getString("city"); long local = r.getLong("local_count"); globalCount.merge(key, local, Long::sum); } } -- Reduce 阶段：globalCount 即最终结果</p>

若需分页或 TopN，可在 Map 阶段加 LIMIT，但需注意精度损失——更稳妥的是分片返回足够多候选（如 Top 100），中央节点再取全局 Top 10。