分库分表后，传统的 LIMIT offset, size 分页方式会变得低效且复杂，主要会遇到深度分页性能暴跌、结果不准确和多维度排序困难等问题。其核心原因在于数据分散存储导致全局有序性缺失。
解决此问题，有几种主流的方案。下面我用一个表格为你快速梳理它们的核心思想、优缺点和典型适用场景，方便你根据自身情况做出选择。
| 方案 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 基于游标的分页 | 利用上一页最后一条数据的排序字段值（如ID、时间戳）作为查询起点，避免使用 OFFSET | 性能极佳，与页码无关，内存消耗稳定 | 不支撑随机跳页 | 信息流、连续浏览（如社交媒体、新闻推送） |
| 全局索引表 | 建立独立表（或使用Elasticsearch等）存储所有信息的排序字段与主键及分片路由信息 | 支持任意字段排序和随机跳页 | 需维护额外表，存在同步延迟和复杂度 | 多维度排序（如排行榜）、强跳页需求 |
| 二次查询优化 | 先在各分片查询主键和排序字段，在应用层排序后，再根据主键查询详细数据 | 减少数据传输量，建立相对轻松 | 深度分页时性能依然下降明显 | 浅分页（如后台管理系统，Offset < 1万） |
| 专用中间件/数据库 | 将数据同步到如Elasticsearch或TiDB等更适合做复杂查询的体系，由它们处理分页 | 性能高，工业界常用方案 | 需保证信息同步一致性 | 对性能和实时性要求较高的架构 |
实践建议与注意事项
选择方案后，以下几点能帮助你更好地实施：
- 排序字段务必保证全局唯一：为避免分页结果出现重复或遗漏，排序条件应组合使用业务排序字段（如时间戳）和唯一标识字段（如 ID），例如
ORDER BY create_time DESC, id DESC。 - 考虑业务妥协：并非所有场景都需要复杂的跨分片分页。与产品经理沟通，限制查询范围（如只允许按时间过滤后查询，或提示用户“仅显示部分结果”），是直接且有效的规避方式。
- 让分片键和排序键尽量对齐：在系统设计初期，若是可能，尽量选择高频的排序字段作为分片键。这样可以极大减少跨分片的查询，降低聚合复杂度。
- 监控数据倾斜：定期检查各分片的数据量和查询响应时间，避免因数据倾斜导致热点分片成为性能瓶颈。
总结
分库分表后的分页查询没有一劳永逸的完美方案，核心思路是避免使用传统的 OFFSET 偏移量机制。选择哪条路径，取决于你的具体业务场景和需求：
- 追求极致性能的深度分页（如信息流）：基于游标的分页是最佳选择，尽管它不支持跳页。
- 需要多维度排序或随机跳页（如排行榜）：考虑全局索引表方案或专用中间件/数据库（如Elasticsearch），但需接受其额外的维护开销和同步延迟。
- 仅涉及浅分页（如后台管理系统）：可考虑二次查询优化。
- 最简单直接的方法：尝试从业务层面规避跨分片分页查询。
希望这些信息能援助你做出合适的技术决策。
 E. Yet Another MEX Problem)
