分库分表环境下分页查询的五大解决方案

1. 分库分表环境下分页查询的核心挑战

在千万级数据量的业务场景中，分库分表已成为解决MySQL单表性能瓶颈的标准方案。但当我们真正实施分库分表后，分页查询这个看似简单的功能却变成了一个令人头疼的技术难题。

1.1 单库单表分页的底层机制

在单库单表环境下，分页查询的SQL语法非常简单：

sql复制SELECT * FROM t_order ORDER BY id LIMIT 10000, 10;

其执行流程可以分解为：

1. 按照id字段排序（假设id是主键）
2. 扫描前10010条记录（offset+size）
3. 丢弃前10000条记录
4. 返回剩下的10条记录

这种机制在单表环境下工作良好，因为：

• 所有数据都存储在同一物理表中
• 排序操作是全局有序的
• 即使offset很大，最多只是扫描性能下降，不会出现结果错乱

1.2 分库分表的分片模型

分库分表主要采用水平分片（Horizontal Sharding）策略，常见的有两种分片方式：

哈希分片

java复制// 示例：订单ID取模分片
int shard = orderId % 4;  // 分为4个分片

特点：

• 数据均匀分布，避免热点问题
• 无法预知数据具体位置
• 适合随机读写场景

范围分片

sql复制-- 示例：按ID范围分片
-- 分片0：1-1000000
-- 分片1：1000001-2000000

特点：

• 可以精确定位数据所在分片
• 范围查询性能好
• 可能出现数据分布不均

1.3 分页查询的核心矛盾

当数据被分散到多个分片时，每个分片只包含全局数据的一部分子集。这就导致：

1. 全局有序性丧失：没有一个分片拥有完整的有序数据集
2. 结果合并难题：简单的分片查询合并会导致数据错乱
3. 性能瓶颈：随着offset增大，每个分片需要扫描的数据量线性增长

典型错误示例

假设有2个分片，按order_id哈希分片：

• 分片0（偶数ID）：2,4,6,8,10
• 分片1（奇数ID）：1,3,5,7,9

执行分页查询（第2页，每页2条）：

sql复制-- 分片0执行
SELECT * FROM t_order_0 ORDER BY id LIMIT 2,2;  -- 返回6,8
-- 分片1执行 
SELECT * FROM t_order_1 ORDER BY id LIMIT 2,2;  -- 返回5,7

合并结果排序后得到5,6，而正确结果应该是3,4。这就是分库分表分页最常见的错误。

2. 五大分页方案深度解析

2.1 全局视野法（二次排序法）

实现原理

1. 在每个分片执行全量查询（0到offset+size）
2. 在内存中合并所有分片结果
3. 全局排序后截取目标范围

java复制// ShardingSphere的SQL改写逻辑
originalSQL: SELECT * FROM t_order ORDER BY id LIMIT 10000,10
rewrittenSQL: SELECT * FROM t_order ORDER BY id LIMIT 0,10010

优化技巧

• 流式归并：使用优先级队列实现多路归并，避免全量数据加载
• 并行查询：并发执行各分片查询，减少总体响应时间
• 字段精简：只查询必要字段，减少数据传输量

适用场景

• 后台管理系统
• 小数据量分页（offset < 10000）
• 分片数量较少（<10）

生产案例

某电商后台订单查询系统：

• 16个分片
• 最大允许offset=5000
• 查询耗时控制在2s内
• 采用MyBatis分页插件+ShardingSphere实现

2.2 游标分页法（性能最优方案）

核心思想

用上一页最后一条记录的排序字段值作为游标，替代传统的offset。

sql复制-- 第一页
SELECT * FROM t_order ORDER BY id LIMIT 10;

-- 第二页（假设上一页最后id=10）
SELECT * FROM t_order WHERE id > 10 ORDER BY id LIMIT 10;

实现要点

1. 排序字段必须唯一：推荐使用"创建时间+ID"组合
2. 索引设计：必须为排序字段建立联合索引
3. 前端配合：需要保存last_id并在下次请求时传回

性能对比

适用场景

• APP无限滚动列表
• 消息流
• 任何不需要跳页的C端场景

2.3 分片键精准路由法

最佳实践

当查询条件包含完整分片键时，可以直接路由到特定分片：

yaml复制# ShardingSphere配置示例
spring:
  shardingsphere:
    rules:
      sharding:
        tables:
          t_order:
            actual-data-nodes: ds0.t_order_${0..3}
            table-strategy:
              standard:
                sharding-column: user_id
                precise-algorithm-class-name: com.example.UserIdPreciseShardingAlgorithm

性能优势

• 查询仅在一个分片执行
• 与单表性能完全一致
• 支持任意深度的分页

设计建议

1. 高频查询维度作为分片键
2. 避免使用会变更的字段作为分片键
3. 考虑冷热数据分离

2.4 ES二级索引方案

架构设计

code复制MySQL分片集群 → Canal → Kafka → Elasticsearch

实现步骤

1. 配置Canal监听MySQL binlog
2. 将关键字段同步到ES
3. 查询时先查ES获取ID列表
4. 用ID批量查询MySQL获取完整数据

性能优化

• 使用scroll API处理深分页
• 合理设置refresh_interval
• 只同步必要字段到ES

适用场景

• 复杂条件搜索
• 需要跳页的后台系统
• 数据分析类查询

2.5 范围分片优化法

实现原理

对于按时间范围分片的场景：

code复制分片0: 2023-01月数据
分片1: 2023-02月数据
...
分片11: 2023-12月数据

查询2023年数据第100页：

1. 计算时间范围
2. 只查询包含目标数据的分片
3. 减少扫描分片数量

优化效果

3. 生产环境避坑指南

3.1 排序字段设计规范

错误示例：

sql复制SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000,10;

问题：同一毫秒可能有多条记录，导致分页结果不稳定。

正确做法：

sql复制-- 建立联合索引
ALTER TABLE orders ADD INDEX idx_time_id (create_time, id);

-- 查询使用组合排序
SELECT * FROM orders 
ORDER BY create_time DESC, id DESC 
LIMIT 10000,10;

3.2 深分页限制策略

防护措施：

1. 应用层校验最大offset

java复制if(pageNum > 100){
    throw new BusinessException("最多允许查询100页");
}

2. 数据库层面限制

sql复制-- MySQL执行前检查
EXPLAIN SELECT ... LIMIT 100000,10;

3. 强制添加筛选条件

3.3 分片键选择原则

评估维度：

1. 查询频率（该字段出现在WHERE中的比例）
2. 数据分布均匀性
3. 字段值稳定性
4. 业务增长模式

3.4 跨分片JOIN解决方案

方案对比：

3.5 COUNT查询优化

解决方案：

1. 使用Redis计数器

java复制// 订单创建时
redisTemplate.opsForValue().increment("order_count");

2. MySQL近似计数

sql复制SELECT TABLE_ROWS 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_NAME = 'orders';

3. 定时任务统计

java复制@Scheduled(cron = "0 0 3 * * ?")
public void syncOrderCount(){
    // 夜间统计全量数据
}

4. 方案选型决策矩阵

4.1 技术维度评估

4.2 业务场景匹配

1. 用户中心订单列表

   • 特点：用户只查自己的订单
   • 方案：user_id作为分片键+精准路由

2. 商品搜索列表

   • 特点：多条件筛选，需要跳页
   • 方案：ES二级索引+MySQL回查

3. 运营后台报表

   • 特点：全量数据，深分页
   • 方案：定时任务预生成报表+游标分页

4. 实时消息流

   • 特点：只查看最新，无需跳页
   • 方案：游标分页+Redis缓存最新数据

5. 性能优化进阶技巧

5.1 索引设计最佳实践

联合索引设计：

sql复制-- 好的设计
ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, create_time);

-- 查询示例
SELECT * FROM orders 
WHERE user_id=123 AND status=1
ORDER BY create_time DESC 
LIMIT 10;

索引避坑指南：

1. 避免在索引列上使用函数
2. 注意最左前缀原则
3. 区分度高的列在前

5.2 查询语句优化

优化前：

sql复制SELECT * FROM orders 
WHERE create_time > '2023-01-01'
ORDER BY amount DESC
LIMIT 100000,10;

优化后：

sql复制SELECT o.* FROM orders o
JOIN (
    SELECT id FROM orders
    WHERE create_time > '2023-01-01'
    ORDER BY amount DESC
    LIMIT 100000,10
) tmp ON o.id = tmp.id;

5.3 缓存策略

多级缓存设计：

1. 第一层：本地缓存（Caffeine）
2. 第二层：分布式缓存（Redis）
3. 第三层：数据库

缓存key设计：

java复制String cacheKey = String.format("order:list:%s:%s:%s", 
    userId, 
    DigestUtils.md5Hex(queryParams), 
    pageNum);

5.4 监控与调优

关键监控指标：

1. 分页查询响应时间P99
2. 数据库QPS和CPU使用率
3. ES查询延迟
4. 缓存命中率

调优工具：

1. Explain分析执行计划
2. Arthas诊断慢查询
3. Prometheus + Grafana监控

分库分表环境下的分页查询没有银弹，需要根据具体业务特点选择最适合的方案。在实际项目中，我们通常会组合使用多种方案，比如C端用游标分页，后台用ES方案。关键是要理解每种方案的适用场景和限制，避免在生产环境中踩坑。