周三中午，下班刚一会，我们技术组点的几份外卖就到了，大家纷纷接过手中的快餐，然后开始扒拉着盒饭，此时这个只属于技术组的办公室里飘满了饭香菜香和咀嚼声，约摸半个小时，有人开始收拾饭盒，有人靠在椅背上刷手机，有人盯着屏幕发呆。

“反正现在没事干，不如小王继续分享上次的面试战况。”善于找话题的小李开口道。

“可以的，上次面试被问到那个分库分表的分页问题，把我问得够呛，现在可以继续和大家一起复盘复盘。你们先看看这个分库分表下的分页方案，然后咱们再聊聊这个话题。饭后多说话也是有助于消化的。”小王笑着答应道。

于是众人纷纷看了起来，不一会，有人说；“看完了，开始吧。”

“好的。那咱们开始。”于是小王开始了他的表演。

“面试官先让我分析，什么情况下分库分表会出现分页问题。我说，如果按用户ID取模分片，按创建时间全局排序分页，这就必须跨库跨表查询了。反之，如果是按时间范围分片，查询某个时间段的订单，而且排序字段就是这个时间字段，那其实还是在单分片内操作，分页没问题。”小王说道。

“接下来面试官让我给出解决方案。我先说了全局查找法。’从第0条开始找，然后找的范围也会更大，例如我们就会找到第0条到第4条的数据。’”小王模仿着面试时的语气继续讲道。“当然找到之后我们还需要在应用程序当中进行合并以及排序再分页，最终拿到我们当前页所需要的数据。’”

“但这样翻页越深性能会越差吧？”小李插话道。

“没错！”小王稍微提高了点音量，然后继续道：“‘到了这里，我相信你会认识到一个问题，也就是翻页越深性能会越差，因为我们是从第0条开始找，对不对？’那假如说我翻到了第10万条，所以就像我们之前所说的这种极端情况，它有可能都在一个节点当中，所以我们必须从第0条开始去找，所以这里涉及到的数据量就会很大了。’”

“所以我紧接着提出了禁止跳页查询法，”小王继续道，“‘我们可以拿到上一页的最大ID作为过滤的条件，这样我们就不用从第0条开始找了，只需要去过滤到当前这一页的数据即可。’”

“但这时面试官追问：‘如果产品坚持要支持随机跳页呢？有没有更好的架构方案？然后我说’此时ES和ShardingSphere该上场了。当分页查询变得复杂时，我们可以考虑换条路——把分页需求迁移到Elasticsearch。想象一下，ES天生就是分布式的，它把数据分片存储，查询时自动聚合结果。你不再需要手动在各个MySQL分片间协调。”小王说道。

“如果不愿意引入ES，ShardingSphere可以成为你的智能查询优化器。它会自动改写你的SQL，比如你写SELECT * FROM orders ORDER BY create_time LIMIT 10000, 20。ShardingSphere会帮你：SQL自动改写：在每个分片执行LIMIT 0, 10020；流式归并：采用归并排序算法，边拉取数据边排序；智能过滤：最终只返回第10000-10020条记录。“小王接着说道。

“如果以上方案都不行，”小王补充道，“最后的选择是业务妥协。”

“比如：”

• 只查询当前用户所在分片的数据

• 提示用户“仅显示最近三个月订单”

• 提供搜索功能代替深度分页

“但这里有个关键，技术方案的选择权，取决于产品对用户体验的容忍度。”

“所以现在如果再有面试官问这个问题，我的回答会是这样的分层方案：

第一层：业务优化
“先判断是否真的需要跨分片分页，能否通过业务设计规避？”

第二层：技术优选

1. 简单场景：禁止跳页查询法（满足80%需求）

2. 中等复杂：ShardingSphere中间件方案（透明升级）

3. 复杂场景：Elasticsearch搜索引擎方案（终极武器）

第三层：架构思维
“分页问题的本质是数据分布与查询模式的匹配问题。好的架构应该在设计分片策略时，就考虑最常见的查询路径。”小王总结道。

“原来一个分页问题，能引出这么多架构思考。”小李感慨道。

“是啊，技术方案没有最好，只有最合适。 在小公司，可能禁止跳页就够了；在中等规模，ShardingSphere是性价比之选；到了大厂级别，ES可能才是标配。但无论选择哪种方案，”小王补充道，“都要明白背后的取舍——是选择开发简单，还是选择用户体验，或是选择系统复杂度。”

”差不多了吧，咱们现在到午睡时间了。“可能听得有些懵逼的小宋插话道。

于是众人纷纷不说话了，办公室里逐渐安静了下来，大家纷纷拿出午睡床午睡椅子开始休息了。

阅读原文：原文链接