需求与选型:大表为什么要拆
项目的起点是一张订单主表:2 亿行,每天还在涨 80 万行。大促时一条按订单号查详情的语句要跑 800 毫秒,DBA 每周都要处理一次慢查询告警。这本书记录我们团队把这张大表拆掉的全过程。
本篇先回答三个问题:瓶颈到底卡在哪、拆分方案有哪几种、机器与中间件怎么选。不急着上代码——选型错了后面全是返工。我们最早按用户 ID 哈希分片,结果发现按订单号查询要扫全片,不得不推翻重来,这个教训贯穿全书。
| 章节 | 内容 | 你将获得 |
|---|---|---|
| 1.1 需求拆解 | 单库瓶颈与查询热点 | 知道哪里慢、为什么慢 |
| 1.2 选型对比 | 垂直拆、水平拆与分库 | 三种拆法的对照与选择依据 |
| 1.3 机器准备 | MySQL 分片实例规格 | 规格选型与容量估算方法 |
| 1.4 技术栈对齐 | 中间件与云产品 | ShardingSphere 与云服务怎么配合 |
全书围绕一个真实订单系统展开,用到的腾讯云产品包括云数据库 MySQL、云数据库 Redis、对象存储 COS 与日志服务 CLS。新购实例可以参考 腾讯云云数据库特惠。
如果你也在做订单系统的拆分,推荐先看 Java 实战:订单系统 里同一业务的单体实现,对照着看更清楚分库分表到底解决了什么问题。
延伸阅读
- Java 实战:订单系统:单体订单系统的原始形态,拆分前的业务全貌
- Go 实战:IM 系统:中间件层与连接池治理的对照思路
