应使用全局唯一递增ID实现游标分页替代OFFSET：SELECT FROM order_001 WHERE id > 12345 ORDER BY id LIMIT 20；id需全局唯一有序（如雪花ID），禁用单独create_time；管理后台等特殊场景可多分片并行查+应用层归并，但须熔断；count()应避免，改用近似值或异步汇总。
全局唯一递增 ID 代替 OFFSET
分库分表后 OFFSET 分页会跨多个物理分片扫描，导致性能断崖式下降，尤其在深分页（如 OFFSET 100000）时几乎不可用。根本原因是各分片数据分布不均、排序不一致，LIMIT OFFSET 无法保证逻辑顺序。
实际做法是放弃 OFFSET，改用「游标分页」：依赖某个严格单调递增且全局唯一的字段（如 id 或 create_time + sharding_key 组合），每次查询带上上一页最后一条的值：
SELECT * FROM order_001 WHERE id > 12345 ORDER BY id LIMIT 20;注意点：
-
id必须是全局唯一、写入有序的（比如用雪花 ID 或数据库自增 ID 配合号段模式） - 不能用
create_time单独做游标，高并发下可能重复，需搭配id或分片键去重 - 首次查询无游标，直接用
ORDER BY id LIMIT 20；后续请求必须携带上一页末尾的id - 如果业务要求“跳转到第 N 页”，需前端禁用输入页码，或后台转成近似游标（但精度不可靠）
多分片结果合并排序（慎用）
当必须支持随机页码（如管理后台导出第 50 页），且数据量可控（百万级以内），可走「各分片并行查 + 应用层归并」路径。但这是兜底方案，不是常规解法。
典型流程：
- 向所有相关分片（如
order_001~order_008）下发相同条件的select ... ORDER BY create_time DESC LIMIT 100（取足够大的LIMIT，比如目标页大小 × 分片数） - 应用层将 8 × 100 = 800 条结果按
create_time全局排序，再截取对应页（如第 50 页 → offset=980, limit=20） - 缺点明显：网络 IO 倍增、内存占用高、排序不稳定（时间相同则顺序未定义）
务必加熔断：若单次合并条数超阈值（如 5000），直接报错或降级为游标分页提示。
Count(*) 总数怎么算？
分库分表下 COUNT(*) 跨分片执行成本极高，多数场景应避免实时总数展示。
可行替代方案：
- 用近似值：基于统计信息（如 mysql 的
INFORMATION_SCHEMA.TABLES中的TABLE_ROWS，误差可能达 40%） - 异步汇总：写入时用 redis HyperLogLog 或单独汇总表记录增量，定时对账
- 前端模糊表达：“已显示 20 条，更多结果请继续浏览” —— 彻底去掉总数依赖
- 真要精确总数？只能全分片扫，但应限制条件（如加时间范围）+ 设置超时（
max_execution_time）+ 记录慢日志告警
ShardingSphere 等中间件的分页行为
ShardingSphere 默认把 LIMIT 10 OFFSET 20 拆成 LIMIT 30 下发到每个分片，再内存归并取 20 条。这看似省事，实则放大了问题：每个分片都返回冗余数据，IO 和 CPU 双重浪费。
关键配置项：
-
props: sql-show: true开启后可看到实际下发到各分片的 SQL，验证是否真的被改写 -
sql-parser-cache-enabled: true加速解析，但对分页无实质优化 - 真正有效的是关掉自动改写：
sql-comment-parse-enabled: false并手动使用游标语句，中间件不会干涉
别迷信中间件的“透明分页”能力 —— 它解决的是语法兼容，不是性能本质。真正的分页治理，得从 SQL 设计源头控制。
游标字段选什么、怎么索引、如何应对删除导致的空洞、分页缓存要不要做……这些细节一旦漏掉，线上就容易出现漏数据或重复数据。比写对 SQL 更难的，是让整个链路对“顺序”有共识。