📄 一句话概括
关系模型赢在更新成本低（拆表保证一处改处处对），但代价是连接有延迟、难以分散到多台机器——优点缺点是同一枚硬币的两面。
📝 本节和前面几节的关系
2-3 的【拆表＋连接】既是本节优点的来源（拆表→更新成本低）也是缺点的来源（连接→延迟）。本节把账算全，并为 2-5 的【NoSQL 为什么会出现】铺路——【难分散】正是那边的引子。
一、优点：更新成本低
2-3 拆表的核心回报：
- 张三的电话只存一处（顾客表），改手机号改一行，所有历史订单查出来都是新号码
- 想想不拆表的对照：下过 500 单就要改 500 处，漏 1 处就是数据不一致
更新成本＝改一个信息要动多少地方。 拆表把它压到最低——这是关系模型最重要的优点，银行账务、库存管理这类【错一个数就出大事】的场景全靠它。
配合 1-4 的另外几件本事（约束拦错、事务保证【要么全成要么不成】），关系型数据库成了【正确性】的代名词。
二、缺点一：连接有延迟
拆表拆散了数据，用的时候要当场连接：
- 三五张小表，连接瞬间完成，没感觉
- 表到百万、千万行级，连接的计算量上来了——每次查询都现算一遍【对号配对】，响应就慢了
这是结构性的代价：存的时候拆得越细，查的时候拼得越费劲。 分析类查询（1-7 的月底报表）动辄横跨好几张大表，延迟尤其明显。
三、缺点二：难以分散
数据库坐大之后，一台服务器装不下、扛不住了，自然的想法是分散：把数据拆开放到 10 台机器上。
关系模型在这里撞墙：
- 连接是跨表的——订单在 3 号机、顾客在 7 号机，连接就要跨机器跑网络，慢一个数量级
- 事务要求【要么全成要么不成】（1-4 的控制）——一笔交易跨 5 台机器，要让 5 台【要么同时成功、要么同时回滚】，协调成本极高
- 拆到哪台也头疼——按什么字段切分，才能让查询均匀落到各台机器？
一句话：关系模型天生是【一台机器上追求正确】的设计，搬到几百台机器上就很别扭。
四、优缺点对照表
| 内容 | 来源 | |
|---|---|---|
| 优点 | 更新成本低、数据一致性高 | 拆表：同一信息只存一处 |
| 缺点一 | 连接延迟（大表多表查询慢） | 连接要当场现算 |
| 缺点二 | 难以分散（不易横向扩展） | 连接跨机器＋事务协调难 |
注意：优点和缺点同源——都是【拆表】这套设计造出来的。这不是设计失误，是取舍。
五、动手 Demo：算一笔更新成本账
数据：某顾客下过 10 笔订单，改名了。
- 不拆表（订单表里每行都写顾客姓名电话）：改名要
UPDATE几行？——10 行（下过 1000 单就是 1000 行） - 拆表（2-3 的三张表结构）：改名
UPDATE几行？——1 行（顾客表那一行） - 再算延迟账：月底报表要【订单×顾客×商品】三表连接，订单表 500 万行——连接是在每次查询时都要现做一遍的
看到什么算成功：两个数字【10 行 vs 1 行】和【每次查询现连接】——前一个是优点，后一个是缺点，都出自同一套拆表设计。
六、30 秒实验
想想 12306 春运抢票：几亿人同时查余票。
- 余票查询就是【车次表×区间表×订单表】的连接计算——春运的查询量级，连接延迟被放大到极限
- 12306 实际动用了大量缓存和分库手段来扛——【难以分散】这个缺点，现实里就是这么被硬扛的
七、常见误区
- "关系模型有缺点，所以设计得不好" —— 取舍而非失误：在【单机追求正确】的年代它是最佳设计；只是互联网时代【海量＋分散】成了新需求，2-5 的 NoSQL 应运而生。
- "更新成本低是说改数据快" —— 是说改得少且不会不一致（只改一处），不是改的速度快；一行
UPDATE本身快不快另说。 - "连接延迟是数据库写得烂" —— 不是烂，是结构性代价：拆得越细、表越大，配对计算越多。谁来做都要付这个成本。
自测三问（点开对答案）
1. 关系模型最重要的优点是什么？来源是什么？ **更新成本低、一致性好；来源是拆表——同一信息只存一处**。 2. 两个缺点是什么？ **连接延迟（当场现算配对）、难以分散（跨机连接＋事务协调难）**。 3. 优点和缺点共同的设计根源是什么？ **拆表 ＋ 连接**这套关系模型的基本手法——同一枚硬币的两面。- ☐ 下一节（2-5 NoSQL-非关系模型）
相关笔记
- 表连接-将各种表组合在一起 —— 上一节：优缺点全由【拆表＋连接】派生
- 🗄️ 数据库基础 · 索引 —— 全课路线图