垂直拆分：按业务与按读写特征切
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 23/49 篇 · 🚧 占位待学
上一篇：《拆前穷尽：别急着分库分表》
下一篇：《水平拆分与分片键：一次选择，决定后半生》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.2
一、本文要解决的问题
一个大库装所有业务，订单表的热更新和用户表的冷查询抢同一块 buffer pool，任何一张大表的事务都拖累所有人。垂直拆分按「业务边界」切库、按「读写特征」切表——它是微服务拆分在数据层的镜像，也是水平拆分的前置动作。
二、知识点清单
- 垂直分库：按业务域拆（订单库 / 用户库 / 商品库），与微服务边界的对应关系
- 垂直分表：宽表拆冷热列（高频小字段 vs 低频大字段），减少回表与 IO
- 拆后 join 怎么办：冗余字段（订单表冗余商品名）、应用层聚合（并行调接口）、数据异构（ES）
- 拆后跨库事务怎么办：放弃数据库层事务 → 最终一致（可靠消息 / TCC，深挖见分布式事务总纲）
- 拆分的实施步骤：双写过渡 → 迁数据 → 切读 → 切写 → 下线旧库
三、动手实验（学习时必须真跑）
- 把示例系统的单库拆成订单 / 用户 / 商品三库（Docker 三实例）
- 改造「订单列表页」：原来 join 查询，改冗余字段版与接口聚合版各实现一遍，压测对比 RT
- 跨库下单场景用本地消息表保证最终一致，制造消费失败验证补偿
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。