SQL 分库分表下分页如何实现？

应使用全局唯一递增ID实现游标分页替代OFFSET：SELECT FROM order_001 WHERE id > 12345 ORDER BY id LIMIT 20；id需全局唯一有序（如雪花ID），禁用单独create_time；管理后台等特殊场景可多分片并行查+应用层归并，但须熔断；COUNT()应避免，改用近似值或异步汇总。

全局唯一递增 ID 代替 OFFSET

分库分表后 OFFSET 分页会跨多个物理分片扫描，导致性能断崖式下降，尤其在深分页（如 OFFSET 100000）时几乎不可用。根本原因是各分片数据分布不均、排序不一致，LIMIT OFFSET 无法保证逻辑顺序。

实际做法是放弃 OFFSET，改用「游标分页」：依赖某个严格单调递增且全局唯一的字段（如 id 或 create_time + sharding_key 组合），每次查询带上上一页最后一条的值：

SELECT * FROM order_001 WHERE id > 12345 ORDER BY id LIMIT 20;

注意点：

• id 必须是全局唯一、写入有序的（比如用雪花 ID 或数据库自增 ID 配合号段模式）
• 不能用 create_time 单独做游标，高并发下可能重复，需搭配 id 或分片键去重
• 首次查询无游标，直接用 ORDER BY id LIMIT 20；后续请求必须携带上一页末尾的 id
• 如果业务要求“跳

  

  转到第 N 页”，需前端禁用输入页码，或后台转成近似游标（但精度不可靠）

多分片结果合并排序（慎用）

当必须支持随机页码（如管理后台导出第 50 页），且数据量可控（百万级以内），可走「各分片并行查 + 应用层归并」路径。但这是兜底方案，不是常规解法。

典型流程：

• 向所有相关分片（如 order_001 ~ order_008）下发相同条件的 SELECT ... ORDER BY create_time DESC LIMIT 100（取足够大的 LIMIT，比如目标页大小 × 分片数）
• 应用层将 8 × 100 = 800 条结果按 create_time 全局排序，再截取对应页（如第 50 页 → offset=980, limit=20）
• 缺点明显：网络 IO 倍增、内存占用高、排序不稳定（时间相同则顺序未定义）

务必加熔断：若单次合并条数超阈值（如 5000），直接报错或降级为游标分页提示。

Count(*) 总数怎么算？

分库分表下 COUNT(*) 跨分片执行成本极高，多数场景应避免实时总数展示。

可行替代方案：

• 用近似值：基于统计信息（如 MySQL 的 INFORMATION_SCHEMA.TABLES 中的 TABLE_ROWS，误差可能达 40%）
• 异步汇总：写入时用 Redis HyperLogLog 或单独汇总表记录增量，定时对账
• 前端模糊表达：“已显示 20 条，更多结果请继续浏览” —— 彻底去掉总数依赖
• 真要精确总数？只能全分片扫，但应限制条件（如加时间范围）+ 设置超时（max_execution_time）+ 记录慢日志告警

ShardingSphere 等中间件的分页行为

ShardingSphere 默认把 LIMIT 10 OFFSET 20 拆成 LIMIT 30 下发到每个分片，再内存归并取 20 条。这看似省事，实则放大了问题：每个分片都返回冗余数据，IO 和 CPU 双重浪费。

关键配置项：

• props: sql-show: true 开启后可看到实际下发到各分片的 SQL，验证是否真的被改写
• sql-parser-cache-enabled: true 加速解析，但对分页无实质优化
• 真正有效的是关掉自动改写：sql-comment-parse-enabled: false 并手动使用游标语句，中间件不会干涉

别迷信中间件的“透明分页”能力 —— 它解决的是语法兼容，不是性能本质。真正的分页治理，得从 SQL 设计源头控制。

游标字段选什么、怎么索引、如何应对删除导致的空洞、分页缓存要不要做……这些细节一旦漏掉，线上就容易出现漏数据或重复数据。比写对 SQL 更难的，是让整个链路对“顺序”有共识。