count 汇总九个片返回九个数字 总数为什么要自己加

后台首页要显示今日订单数，接口返回的是一个长度 9 的数组，前端直接渲染成 9 个数字，运营截图来问哪个才是总数。第一次遇到会往复杂处想，其实漏掉的多是个小前提。

SELECT SUM(c) FROM (
  SELECT count(*) AS c FROM t_order_00 WHERE create_time >= '2026-11-14'
  UNION ALL
  SELECT count(*) FROM t_order_01 WHERE create_time >= '2026-11-14'
) t;

中间件把 count 下推到每个分片执行，各片返回自己的局部结果，没有做二次汇总。驱动层把多结果集原样交给应用，代码里按单库的习惯只取第一行。这一点先确认清楚，后面就不用反复试。

「分片聚合统计」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。

改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。

具体做法是，在 DAO 层识别多结果集 把各片 count 相加；sum 能直接相加 avg 要按 count 加权；需要精确去重时用独立字段集合或走离线表；接口只返回单值 并在日志里记录各片明细。

改完照着核一遍，首页只显示一个总数 和单库统计结果一致。