批处理分片跑 分片键没选好有的片要跑两小时

同一个批处理拆成八个分片并行跑 七个十分钟就结束 剩下那个跑了将近两小时 整体完成时间被它一个拖住。乍看像缓存或者权限的锅，追下去往往不是。

SELECT MOD(user_id,8) AS shard, COUNT(*) FROM orders
  WHERE created_at >= '2026-11-01' GROUP BY shard;
SELECT MIN(id), MAX(id) FROM orders
  WHERE created_at >= '2026-11-01';

追下去是这么回事：按用户编号取模分片 头部几个大客户占了绝大部分订单 分片粒度对不上数据分布 分片数加得再多也压不平这条长尾。

「批处理分片不均」这类改动最怕改一半，回滚脚本先准备好，再动生产。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。

先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。

具体做法是，先用分组统计看各分片的实际数据量 不要凭感觉切；改按订单号或者时间区间切 让每片条数尽量接近；实在压不平就把大客户单独拆一片 再继续细分。

验收就看一点，八个分片的耗时差距收在两倍以内 整体完成时间明显缩短。