📌 分库分表分页实现方案 + 主流中间件解析

1️⃣ 问题背景

在高并发互联网系统中，随着数据量不断增长，单表数据很容易突破千万甚至亿级规模。此时传统数据库分页（LIMIT offset,size）会出现严重性能问题，查询延迟急剧上升。

为了解决这一问题，系统通常会引入分库分表架构，将数据按规则拆分到多个数据库或表中，从而实现水平扩展能力。

但一旦进入分库分表架构，分页问题就变成一个分布式查询与排序问题，而不是简单SQL问题。

2️⃣ 核心原理

分库分表分页的本质，是在分布式数据环境下完成“局部有序数据的全局归并排序”。

每个分片内部可以保证局部排序，但跨分片无法直接进行数据库级别的全局排序，因此必须借助应用层或中间件进行数据合并。

分页难点本质

核心难点在于“全局排序无法下推到单个节点完成”。

3️⃣ 数据结构分析

分片数据结构模型

分库分表后，每个分片可以抽象为一个有序集合结构：

分页的本质就是对多个有序数组进行多路归并。

核心数据结构

• 最小堆（Min Heap）
• 优先队列（PriorityQueue）
• 游标 Cursor
• 分片路由表 Sharding Map

4️⃣ 算法分析

多路归并算法

分库分表分页的核心算法是“多路归并排序”，类似于归并排序的分布式版本。

时间复杂度：O(N log K)，K为分片数量。

深分页问题

当 offset 变得非常大时，所有分片都需要扫描大量无用数据。

5️⃣ 执行流程

传统分页流程

优化分页流程（游标模式）

游标分页避免了offset扫描，是高性能分页的关键优化手段。

中间件介入流程

6️⃣ 实际案例

订单系统分页

在电商订单系统中，通常按照 user_id 或 order_id 进行分库分表：

查询用户订单列表：

时间排序分页问题

如果排序字段不是分片键，会导致跨分片排序成本显著增加。

7️⃣ 主流中间件方案

1️⃣ ShardingSphere

• 自动路由分片
• SQL改写
• 结果归并
• 支持分页优化

分页能力：内置 Merge Engine 支持流式归并分页。

2️⃣ MyCAT

• SQL解析
• 全局排序
• 结果合并

但维护成本较高，生态逐渐被 ShardingSphere 替代。

3️⃣ Vitess

• 支持大规模分片
• 高性能路由
• 强一致性支持

4️⃣ TDDL（Taobao Distributed Data Layer）

• 分库分表
• 读写分离
• 基础分页归并

8️⃣ 面试常见问题

Q1：分库分表为什么分页困难？

Q2：如何优化深分页？

Q3：ShardingSphere如何实现分页？

Q4：MyCAT还能用吗？

Q5：分页一定需要中间件吗？

9️⃣ 总结

分库分表分页本质是一个分布式排序问题，核心挑战在于如何在多个数据源之间实现高效的全局排序与分页能力。

从架构演进角度看，分页问题已经从数据库问题演变为分布式系统问题，而中间件则是解决这一问题的核心基础设施。