跨分片难题：分页、聚合与跨库事务
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 26/49 篇 · 🚧 占位待学
上一篇：《全局唯一 ID：雪花算法与时钟回拨》
下一篇：《ShardingSphere 实战与平滑扩容》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.5
一、本文要解决的问题
拆成 64 张表后，产品提了个「小小」的需求：按时间排序看第 3 页、统计本月总 GMV、后台按商家名搜索——每一个都是跨分片的噩梦。这一篇把跨分片三类难题（查询 / 聚合 / 事务）的解法与代价摆全，很多「分库分表后查询变慢」的事故根因都在这里。
二、知识点清单
- 跨分片分页：各分片取 top N 归并（代价随页码暴涨）、禁止跳页 + 游标翻页、二次查询法
- 跨分片聚合：汇总表（定时 / 实时统计）、异构到 ES / ClickHouse（查询与交易分离）
- 跨库事务三选一：放弃强一致走最终一致（可靠消息）、TCC、Seata——选择树回顾（深挖见分布式事务总纲）
- ShardingSphere 对跨库查询的处理：内存归并、流式归并的条件与限制
- OLTP 与 OLQL 分离：为什么分库分表系统最后都会长出一个异构查询集群
三、动手实验（学习时必须真跑）
- 跨 4 分片做「按时间排序第 3 页」：实现归并版与游标版，对比 SQL 数量与 RT 随页码的衰减
- 用 canal 把分片数据同步到 ES，实现商家名搜索走 ES、交易走 MySQL 的双链路
- 跨库下单用可靠消息最终一致实现，压测验证中间态可见性与最终一致
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。