📄 一句话概括
访问量涨了只有两条路：纵向扩展＝换更强的机器（Scale Up），横向扩展＝加更多的机器（Scale Out）——前者简单有天花板，后者能装但难拆。
📝 本节和前面几节的关系
索引（7-7）能救单条慢查询，救不了总量增长：用户翻倍、连接翻倍，单机再快也扛不住。本节讲扩容的两条路线，它是 6-3 成本账（扩容方式影响成本结构）和 2-4 关系模型缺点（「难分散」）的正面回应。
一、两条路线
| 纵向扩展（Scale Up） | 横向扩展（Scale Out） | |
|---|---|---|
| 做法 | 换更强 CPU/内存/磁盘 | 加更多机器分担负载 |
| 改造难度 | 低（换机器即用） | 高（数据要拆、要同步） |
| 天花板 | 有（单机物理极限） | 几乎没有 |
| 成本曲线 | 越往上越贵（顶级硬件溢价） | 累加式，用多少买多少 |
| 故障影响 | 一台全挂 | 单台挂了还有别的 |
二、横向扩展的两难：数据怎么拆
- 读写分离：写进主库，读走多台从库（配合 7-9 同步复制）——最常用，读书多写少的业务最受益
- 分表/分库：按用户或业务切开（2-4 说的「难分散」正是关系模型在这里的短板）
- 负载均衡：请求分配器把流量均匀撒到各台机器
三、动手 Demo：判断该走哪条路
书评网站的三个人生阶段：
① 1 万用户：单机＋索引（7-7）—— 别过度设计
② 50 万用户：读写分离（纵向→横向过渡）—— 读请求占九成，从库扛读
③ 5000 万用户：分库分表＋负载均衡 —— 全套横向
判断顺序：先索引（最便宜）→ 再读写分离 → 最后拆库
── 每往右一步，复杂度翻倍，能不拆就不拆。
【准备块】无——决策沙盘推演。
四、30 秒实验
把「纵向 vs 横向」想成搬家：房间不够住，纵向＝把床换成上下铺、再换大房子（总有极限）；横向＝再买一套房让家人分住（但要决定谁住哪、东西怎么分——分法就是难题）。
五、常见误区
- 「直接上分布式才专业」：单机＋索引能扛住大多数中小系统——先廉价手段，后重型武器
- 「纵向扩展没有尽头」：顶级机器又贵又有物理极限，且单点故障一挂全挂
- 「加了机器就自动变快」：数据不拆开、复制不同步，加机器只是加电费（配合 7-9 才成立）
自测三问
1. 两条路线的本质区别？（加单机性能 vs 加机器数量——简单有顶 vs 能装难拆） 2. 关系模型在横向扩展上的短板是什么？（2-4 说的「难分散」——拆库后连接与一致性变难） 3. 扩容手段的性价比顺序？（索引 → 读写分离 → 分库分表，能不拆就不拆）- ☐ 下一节（7-9 同步复制-复制并运行数据库）
相关笔记
- 索引-缩短获取数据的时间 —— 扩容前的第一招永远是索引
- 更新成本、延迟、分散-关系模型的优点与缺点 —— 「难分散」短板在本节正面接招
- 同步复制-复制并运行数据库 —— 下一节：读写分离的基石
- 🗄️ 数据库基础 · 索引 —— 全课路线图