分表后跨分片ORDER BY + LIMIT或聚合性能差是架构必然结果；需用游标分页替代offset分页，并为排序字段建联合索引，聚合查询应避免实时下推而采用预计算或客户端汇总。
分表后跨分片做 ORDER BY + LIMIT 或 COUNT(*)、SUM() 等聚合，性能差不是配置问题，是架构层面的必然结果——MySQL 本身不感知分片逻辑，每个分片独立执行 SQL，结果在应用层合并时既无法复用索引排序，也无法避免重复扫描和无效丢弃。
为什么直接并行查各分表再合并会错且慢
典型错误写法是：对 user_0 到 user_7 同时执行 SELECT * FROM user_k ORDER BY create_time DESC LIMIT 1000, 20，然后在代码里把 8×20 = 160 条结果排序取前 20。这会导致：
- 精度丢失：比如第 1000 条实际在
user_3，但其他表各自只返回了前 20 条，user_3的第 1000 条根本没被拉上来 - 数据放大：为保精度，你得让每张表都查
LIMIT (offset + size) * N（N 是分片数），8 个分片 × 1000 行 = 8000 行传输，内存合并开销陡增 - 排序失效：各分表的
create_time索引无法跨表联合使用，最终排序只能在应用内存里做，CPU 和 GC 压力直线上升
用游标分页替代 offset 分页（必须改业务逻辑）
这是唯一能绕过跨分片深度扫描的方案，前提是业务接受“只能顺序翻页”。核心是把分页状态从“第几页”转为“从哪条记录之后开始”。例如：
-- 第一页（查出最后一条的 create_time 和 id） SELECT id, create_time, name FROM user_0 ORDER BY create_time DESC, id DESC LIMIT 20; <p>-- 假设最后一条是 create_time='2025-09-10 14:22:03', id=88721 -- 第二页：所有分表都加 where 条件，且必须包含 create_time + id 的联合比较 (SELECT id, create_time, name FROM user_0 WHERE create_time < '2025-09-10 14:22:03' OR (create_time = '2025-09-10 14:22:03' AND id < 88721) ORDER BY create_time DESC, id DESC LIMIT 20) UNION ALL (SELECT id, create_time, name FROM user_1 WHERE create_time < '2025-09-10 14:22:03' OR (create_time = '2025-09-10 14:22:03' AND id < 88721) ORDER BY create_time DESC, id DESC LIMIT 20) -- ... 其他分表同理
注意点：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须用
create_time, id这类**确定性排序字段组合**，单靠时间可能有重复值 - 每个分表查询都要带
LIMIT 20，不能省，否则网络和内存压力失控 - 应用层需对 UNION ALL 结果再做一次全局
ORDER BY create_time DESC, id DESC LIMIT 20，因为各分表只保证局部有序
聚合类查询（COUNT/SUM/AVG）尽量不下推到分片
跨分片 COUNT(*) 如果只是要总数，别在每次请求时算——它几乎永远不变或变化缓慢。更合理的方式是：
- 用定时任务（如每天凌晨）跑全量
COUNT(*)，结果存进一张table_stats表，查总数直接读这张表 - 如果需要实时近似值，开启 MySQL 的
innodb_stats_persistent，查information_schema.TABLES中的TABLE_ROWS字段（误差通常在 ±10% 内） - 真要精确跨分片
SUM(amount)，且不能容忍延迟，那就必须走客户端聚合：每个分表查SUM(amount)，应用层加总。但要注意浮点数精度、NULL 处理、事务一致性（某分表正在写入时快照不一致）
最容易被忽略的坑：排序字段没建联合索引
哪怕你用了游标分页，如果分表中只在 create_time 上建了单列索引，查询依然会慢。因为 WHERE create_time 这种条件，只有 <code>(create_time, id) 联合索引才能高效走索引范围扫描。单列索引下，MySQL 可能回退到全表扫描或 filesort。
检查方式：EXPLAIN 每个分表的查询语句，确认 type 是 range，key 显示用了你建的联合索引，且 rows 接近你预期扫描的行数（比如 limit 20，rows 应该是几百以内，而不是几十万）。
