怎样解决MySQL分表后跨分片聚合与分页查询性能极差问题？-mysql教程-PHP中文网

分表后跨分片ORDER BY + LIMIT或聚合性能差是架构必然结果；需用游标分页替代offset分页，并为排序字段建联合索引，聚合查询应避免实时下推而采用预计算或客户端汇总。

怎样解决mysql分表后跨分片聚合与分页查询性能极差问题？

分表后跨分片做 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 </p>

注意点：

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 处理、事务一致性（某分表正在写入时快照不一致）