分库分表后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 ） - 如果业务允许，优先在应用层做归并排序（取各分片 top-K 后内存合并），但要注意内存和延迟成本
聚合排序（如 GROUP BY + ORDER BY）结果不可信
分库分表中间件（如 ShardingSphere、MyCat）对带 GROUP BY 的语句支持有限，多数只做路由转发，不保证跨节点聚合逻辑正确。例如统计“每个城市销量 Top3 商户”，各分片各自算出自己的 Top3，最终结果只是 3×分片数 条记录，而非全局 Top3。
可行解法取决于场景复杂度：
- 轻量级：应用层拉取全部分片原始数据，在内存中
groupby+sort（适合总数据量 - 中等规模：用 Flink / Spark 做离线/近实时汇总，写回一个宽表供查询
- 强实时要求：引入 Elasticsearch 或 Doris，用其分布式聚合能力替代 MySQL 原生 SQL
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') 并确保所有分片逻辑一致。
