分库分表下的分页查询，到底怎么搞？

来自：juejin.cn/post/7546324539988639790

推荐一个程序员编程资料站：

http://cxyroad.com

副业赚钱专栏：https://xbt100.top

2024年IDEA最新激活方法

后台回复：激活码

CSDN免登录复制代码插件下载：

CSDN复制插件

以下是正文。

今天聊一个分库分表后的经典难题：分页查询。

很多伙伴在面试或者工作里都被问过这个问题，如果没理清楚，容易一头雾水。那我们就用最简单的大白话，把它捋清楚说明白。

1. 不是所有场景都需要分页方案

分页问题只有在 跨库或跨表查询 时才会变复杂。

举个例子：

• 如果查询条件里总是带 分片键（比如查某个用户ID的数据，或者查某个时间片的数据），那它就是查某一个分片的数据。

• 这种情况和查单表一模一样，不存在什么分页难题。

所以第一步一定要问：这次查询到底是不是跨分片的？

2. 三种主流解决方案

当我们真的遇到跨分片分页时，常见的有三种办法：

3. 全局查找法的真相

面试中最喜欢问的就是方案2里提到的 全局查找法。

原理图

问题

正确性没问题，但如果查询第 100,000 页：

• 每个分片要查几十万甚至上百万条数据。

• 内存里还要排序和裁切。

• 极容易 OOM（内存溢出），速度慢到怀疑人生。

所以：全局查找法能用，但翻页浅一点还行，深度翻页会死。

4. 优化：禁止跳页，顺序翻页更香

解决深度翻页问题的最佳实践是：基于上一页最大 ID 翻页。

做法

第 1 页：

SELECT * FROMtableORDERBYidLIMITsize;

第 2 页：

SELECT * FROMtableWHEREid > {上一页最大id} ORDERBYidLIMITsize;

优点

• 每次只查一页，性能极好。

• 和 offset 大小无关，不怕深度翻页。

缺点

• 不能直接跳到第 100 页。

• 只能一页一页往下翻，像刷微博/抖音一样。

但对大多数场景（信息流、消息列表），完全够用。

5. 不推荐的方案：二次查询法

有些文章会提到“二次查询法”。 它实现复杂，还可能遇到数据分布不均的问题，结果不可靠。

一句话：不推荐使用。

6. 面试怎么答（STAR 法则）

如果在面试被问到，可以按 STAR 模型来回答：

S（情境）：系统做了分库分表后，跨分片分页成了难题。

T（任务）：需要一个能保证全局分页正确性的方案。

A（行动）：

• 首先评估业务，能不能限制查询范围，直接规避问题。

• 如果必须实现，首推用Elasticsearch/TiDB这类系统。

• 如果必须在数据库层面搞，就用ShardingSphere的全局查找法，但要说明深度翻页问题。

• 针对深度翻页，再提出“基于上一页最大ID”的优化。

R（结果）：既能满足业务需求，也能保证性能稳定性。

总结

不是所有分库分表都有分页问题，只有跨分片才需要考虑。

常见三类方案：

• 中间件/数据库（推荐）

• 开源框架（方便但有性能坑）

• 业务妥协（直接回避）

全局查找法能用，但深度翻页会炸。

最佳实践：禁止跳页 + 顺序翻页。

一句话总结：

能规避就规避，能交给专用系统就交给专用系统，实在要做就用连续翻页。

<END>

推荐阅读：

副业赚钱推荐：让你的时间开始变现！

免费体验AI图片生成，就在 Image Generator Hub！

程序员在线工具站：cxytools.com 推荐一个自己写的工具站：https://cxytools.com，专为程序员设计，包括时间日期、 JSON处理、SQL格式化、随机字符串生成、UUID生成、文本Hash...等功能，提升开发效 率。 ⬇戳阅读原文直达！ 朕已阅