分库分表后ORDER BY不准是因为数据分散导致局部有序、全局无序;需用唯一组合排序键(如create_time,order_id)并改用游标分页替代OFFSET分页。
ORDER BY 为什么不准了因为数据分散在多个物理库表中,单次查询只能拿到局部有序结果。比如按 user_id 分片,查“最新10条订单”,每个分片返回自己最靠前的10条,合并后整体顺序就乱了——你看到的“第1条”可能实际时间戳比其他分片的“第8条”还晚。
根本原因是:全局排序需要全量数据参与比较,而分库分表天然阻断了跨节点的数据扫描能力。
ORDER BY + LIMIT 分页时数据重复或丢失典型表现是翻页时某条记录反复出现,或者跳过一条不

create_time)存在精度相同、值重复的情况,导致不同分片对“第N条”的判定不一致。
ORDER BY create_time DESC, order_id DESC,避免仅依赖非唯一时间字段LIMIT 20,10 这类偏移分页,改用游标分页(WHERE create_time )
GROUP BY + ORDER BY)结果不可信分库分表中间件(如 ShardingSphere、MyCat)对带 GROUP BY 的语句支持有限,多数只做路由转发,不保证跨节点聚合逻辑正确。例如统计“每个城市销量 Top3 商户”,各分片各自算出自己的 Top3,最终结果只是 3×分片数 条记录,而非全局 Top3。
可行解法取决于场景复杂度:
groupby + sort(适合总数据量
MAX()、MIN() 等聚合函数能直接用吗可以,但必须确认中间件是否支持下推。ShardingSphere 5.x+ 对 MAX/MIN/COUNT 等单值聚合做了优化,会下发到各分片执行,再在内存中二次计算;而老版本或简单代理型中间件(如早期 MyCat)可能只返回第一个分片的结果。
验证方式很简单:手动连两个分片,分别执行 SELECT MAX(create_time) FROM order_01 和 SELECT MAX(create_time) FROM order_02,对比中间件返回值是否等于二者最大值。
容易被忽略的一点:如果排序字段有 NULL,MAX() 会忽略它,但业务上可能需要把 NULL 当作“最早时间”处理——这时得显式写成 COALESCE(MAX(create_time), '1970-01-01') 并确保所有分片逻辑一致。