feat(docs): add interactive demo components for technical appendices

Add placeholder Vue components for visualizing technical concepts across multiple domains including frontend routing, browser rendering, cache design, queue design, database principles, API design, cloud services, and backend evolution. These components provide interactive educational content for the documentation. Update documentation structure to include new appendix sections and enhance existing content with visual components. Remove unused 'codex' dependency from package.json.
2026-02-06 03:34:50 +08:00
parent e8bba6f7c0
commit 7c70c37072
171 changed files with 69830 additions and 6689 deletions
@@ -1,74 +1,82 @@
-# 数据库原理入门：从 Excel 到 SQL
+# 数据库原理入门：为什么淘宝能在 0.01 秒内找到你的订单？

-> 💡 **学习指南**：本章节无需编程基础，我们将从你熟悉的 Excel 表格出发，一步步深入数据库的底层原理。你会明白为什么数据库能从数十亿条数据中瞬间找到你想要的那一条，以及它背后那个神奇的 B+ 树是如何工作的。
-
-<DatabaseQuickStartDemo />
-
-## 0. 引言：当数据像滚雪球一样增长
-
-人类天生擅长处理小数据。一家小店里的账目、一个班级里的学生名单，我们可以轻松地记在脑子里，或者写在纸上。
-
-但是，当数据开始**像滚雪球一样增长**时——从 100 条变成 100 万条，从 1 个用户变成 1 亿个用户——我们遇到了一个核心问题：
-
-**如何高效地存取海量数据？**
-
-这个问题的答案，就是**数据库 (Database)**。
-
-本教程将带你从零开始，一步步拆解数据库这座大厦的构建过程：
-
-1. **存储**：数据是如何从 Excel 进化到数据库的？
-2. **组织**：表、列、行、关系，这些概念到底是什么？
-3. **语言**：如何用 SQL 与数据库对话？
-4. **速度**：为什么数据库能毫秒级查询？（揭秘 B+ 树索引）
+> 💡 **学习指南**：本章节无需编程基础。我们将从一个你熟悉的场景出发——当你在淘宝搜索订单时，系统如何在 10 亿条记录中瞬间定位到你购买的那件 T 恤？答案藏在数据库的底层原理里：B+ 树、索引、事务……我们会用真实的业务案例（淘宝、微信、12306）一步步拆解这些概念。

 ---

-## 1. 数据的进化：从记事本到数据库
+## 0. 引言：当你的 Excel 打不开时

-想象一下，你经营着一家小书店。
+想象一下：

-### 1.1 第一阶段：记事本
+- **场景 A**：你是淘宝的订单系统负责人，今天是大促，1 秒钟有 100 万笔新订单涌入。你的 Excel 还在转圈……
+- **场景 B**：你是微信的工程师，用户正在加载朋友圈，需要瞬间从百亿条动态里找到他好友的 20 条。你的代码还在循环遍历……
+- **场景 C**：你是 12306 的架构师，春运当天，几千万人同时抢票，系统必须保证同一张票不会被两个人同时买到。你的数据库连接池已经耗尽……

-刚开始，你每天卖出几本书，随手记在**记事本**上。
+这三个场景的共同点是：**数据规模已经从"千条"变成了"百亿条"，用户并发从"几人"变成了"千万人"**。

- **优点**：简单，拿笔就能写。
- **缺点**：
-  - 想知道"上个月一共卖了多少钱？"——你得一页页翻，按着计算器算半天。
-  - 想知道"哪本书卖得最好？"——你可能需要手动数每本书出现的次数。
+这时候，Excel 已经完全无法胜任，你需要的是**数据库 (Database)**。
+
+本教程将带你从零开始，理解数据库这座大厦是如何构建的：
+
+1. **存储革命**：数据是如何从 Excel 进化到数据库的？
+2. **关系模型**：表、行、列、主键、外键到底是什么？
+3. **查询语言**：如何用 SQL 与数据库对话？
+4. **性能核心**：为什么数据库能毫秒级查询？（揭秘 B+ 树索引）
+5. **事务安全**：如何保证数据不丢、不乱、不冲突？
+
+<DatabaseEvolutionDemo />
+
+---
+
+## 1. 为什么 Excel 不够用了？从记事本到数据库的进化
+
+### 1.1 当数据只有 100 条时：记事本时代
+
+假设你开了一家小书店，每天卖出几本书。你随手记在笔记本上：
+
+```
+2024-01-15：张三买了《百年孤独》，59元
+2024-01-16：李四买了《活着》，39元
+```
+
+**优点**：零门槛，拿笔就能写。
+
+**缺点**：
+- 想知道"上个月一共卖了多少钱？"——你得一页页翻，按着计算器算半天。
+- 想知道"哪本书卖得最好？"——你可能需要手动数每本书出现的次数。

 这就是**无结构化数据**的困境：数据是死的，想要获得洞察，需要人工大量加工。

-### 1.2 第二阶段：Excel 表格
+### 1.2 当数据增长到 1 万条时：Excel 时代

 生意好了，你开始用 **Excel**。

-你建了一张表，列出了：`书名`、`价格`、`购买者`、`日期`。
+你建了一张表，列出了：`订单号`、`书名`、`价格`、`购买者`、`购买日期`。

-| 书名 | 价格 | 购买者 | 日期 |
-|------|------|--------|------|
-| 百年孤独 | 59 | 张三 | 2024-01-15 |
-| 活着 | 39 | 李四 | 2024-01-16 |
+| 订单号 | 书名 | 价格 | 购买者 | 日期 |
+|--------|------|------|--------|------|
+| 001 | 百年孤独 | 59 | 张三 | 2024-01-15 |
+| 002 | 活着 | 39 | 李四 | 2024-01-16 |

- **优点**：
-  - 可以**自动求和**（SUM 函数）。
-  - 可以**排序**（按价格从高到低）。
-  - 可以**筛选**（只看张三的购买记录）。
- **缺点**：
-  - **容量有限**：当你有 100 万行数据时，Excel 打开都要几分钟，甚至直接卡死。
-  - **难以协作**：你和店员不能同时修改同一个文件，否则会冲突（你得等同事保存关闭后才能编辑）。
-  - **数据不安全**：不小心删了一行，Ctrl+Z 可能救不回来。如果硬盘坏了，数据可能永久丢失。
-  - **数据冗余**：如果张三买了 100 本书，你得在每一行重复写张三的地址和电话。如果张三换了电话，你得修改 100 行。
+**优点**：
+- 可以**自动求和**（SUM 函数）。
+- 可以**排序**（按价格从高到低）。
+- 可以**筛选**（只看张三的购买记录）。
+
+**缺点**：
+- **容量有限**：当你有 100 万行数据时，Excel 打开都要几分钟，甚至直接卡死。
+- **难以协作**：你和店员不能同时修改同一个文件，否则会冲突（你得等同事保存关闭后才能编辑）。
+- **数据不安全**：不小心删了一行，Ctrl+Z 可能救不回来。如果硬盘坏了，数据可能永久丢失。
+- **数据冗余**：如果张三买了 100 本书，你得在每一行重复写张三的地址和电话。如果张三换了电话，你得修改 100 行。

 这就是**单机文件型数据**的瓶颈：它只适合个人或小团队处理中等规模的数据。

-### 1.3 第三阶段：数据库 (Database)
+### 1.3 当数据达到 1 亿条时：数据库时代

 当你的书店变成了"亚马逊"，你需要处理亿级的订单，成千上万的用户同时访问。这时，你就需要**数据库**。

 **数据库，本质上就是一个"超级 Excel"**，但它专为**海量数据**、**高并发访问**和**数据安全**而设计。

-<DatabaseEvolutionDemo />
-
 **核心优势对比**：

 | 特性 | 记事本 | Excel | 数据库 |
@@ -81,7 +89,7 @@

 ---

-## 2. 数据库长什么样？
+## 2. 数据库长什么样？从图书馆的视角理解关系模型

 最流行的数据库类型是**关系型数据库 (Relational Database)**，比如 MySQL、PostgreSQL。它们的样子其实和 Excel 非常像，但概念更加严谨。

@@ -112,6 +120,8 @@
 - **行**：每一行是一个用户（书架上的每本书）
 - **主键**：`user_id`（ISBN 编号，1、2、3 永不重复）

+<DatabaseRelationDemo />
+
 ### 2.2 关系 (Relation)：数据库的灵魂

 这是数据库比 Excel 强大的关键。
@@ -161,11 +171,9 @@
 - **数据一致**：张三换电话，只需要改 `users` 表一行，所有订单关联的电话自动更新。
 - **灵活查询**：可以轻松回答复杂问题，比如"统计每个用户的总消费金额"。

-<DatabaseRelationDemo />
-
 ---

-## 3. 如何和数据库说话？（SQL 入门）
+## 3. 如何和数据库说话？SQL 入门与实战

 你不能直接用鼠标去点数据库（虽然有图形化工具，但本质也是转换成命令），你需要用一种特殊的、标准化的语言来指挥数据库工作。

@@ -184,7 +192,7 @@
 | **U**pdate | 更新/修改 | `UPDATE` | 修改单元格内容 |
 | **D**elete | 删除 | `DELETE` | 删除一行 |

-### 3.2 实战示例：书店管理系统
+### 3.2 实战示例：淘宝订单系统

 假设我们有以下两张表：

@@ -196,13 +204,13 @@
 | 2 | 李四 | 30 | 上海 |
 | 3 | 王五 | 28 | 北京 |

-**图书表 (books)**：
+**商品表 (products)**：

-| book_id | title | price | stock |
-|---------|-------|-------|-------|
-| 101 | 百年孤独 | 59 | 100 |
-| 102 | 活着 | 39 | 50 |
-| 103 | 三体 | 99 | 200 |
+| product_id | name | price | stock |
+|------------|------|-------|-------|
+| 101 | iPhone 15 | 5999 | 1000 |
+| 102 | MacBook Pro | 14999 | 500 |
+| 103 | AirPods Pro | 1999 | 2000 |

 #### 查询数据 (Read)

@@ -224,10 +232,10 @@ SELECT name, age FROM users WHERE age > 25;
 | 李四 | 30 |
 | 王五 | 28 |

-**示例 2**：查找价格在 40 到 100 之间的图书
+**示例 2**：查找价格在 5000 到 15000 之间的商品

 ```sql
-SELECT title, price FROM books WHERE price BETWEEN 40 AND 100;
+SELECT name, price FROM products WHERE price BETWEEN 5000 AND 15000;
 ```

 #### 插入数据 (Create)
@@ -270,32 +278,32 @@ DELETE FROM users WHERE user_id = 4;

 还记得我们讲过的"关系"吗？SQL 最强大的地方在于可以一次性查询多张关联的表。

-**示例场景**：查询"张三购买过的所有图书"
+**示例场景**：查询"张三购买过的所有商品"

 假设我们还有一张订单表 (orders)：

-| order_id | user_id | book_id | quantity |
-|----------|---------|---------|----------|
-| 1001 | 1 | 101 | 1 |
-| 1002 | 1 | 102 | 2 |
-| 1003 | 2 | 101 | 1 |
+| order_id | user_id | product_id | quantity | order_date |
+|----------|---------|--------------|----------|------------|
+| 1001 | 1 | 101 | 1 | 2024-01-15 |
+| 1002 | 1 | 103 | 2 | 2024-01-16 |
+| 1003 | 2 | 101 | 1 | 2024-01-17 |

 **SQL 查询**：

 ```sql
-SELECT u.name, b.title, o.quantity
+SELECT u.name, p.name AS product_name, o.quantity, o.order_date
 FROM orders o
 JOIN users u ON o.user_id = u.user_id
-JOIN books b ON o.book_id = b.book_id
+JOIN products p ON o.product_id = p.product_id
 WHERE u.name = '张三';
 ```

 **返回结果**：

-| name | title | quantity |
-|------|-------|----------|
-| 张三 | 百年孤独 | 1 |
-| 张三 | 活着 | 2 |
+| name | product_name | quantity | order_date |
+|------|--------------|----------|------------|
+| 张三 | iPhone 15 | 1 | 2024-01-15 |
+| 张三 | AirPods Pro | 2 | 2024-01-16 |

 通过 `JOIN`，我们把三张表的数据关联在了一起，得到了完整的答案。

@@ -303,7 +311,7 @@ WHERE u.name = '张三';

 ---

-## 4. 为什么数据库这么快？（索引原理揭秘）
+## 4. 为什么数据库这么快？索引原理与 B+ 树揭秘

 这是数据库最神奇的地方，也是面试中最爱问的问题。

@@ -343,8 +351,6 @@ WHERE u.name = '张三';

 **速度差距**：数千倍甚至数万倍！

-<DatabaseIndexDemo />
-
 ### 4.3 底层数据结构：B+ 树

 真实的索引并不是简单的"字母排序列表"，而是一种精心设计的数据结构，叫做 **B+ 树 (B+ Tree)**。
@@ -394,7 +400,152 @@ B+ 树有一个非常聪明的设计：**它非常"矮胖"**。

 ---

-## 5. 总结与学习路线
+## 5. 事务：当多人同时抢票时，系统如何保证不重复售票？
+
+想象一下春运期间的 12306：
+
+- 时间 T1：用户 A 查询，发现"G1234 次列车还剩 1 张票"。
+- 时间 T2：用户 B 也查询，也发现"还剩 1 张票"。
+- 时间 T3：用户 A 点击"购买"，系统减库存，票卖给了 A。
+- 时间 T4：用户 B 点击"购买"——如果没有保护机制，系统会再次减库存，把同一张票卖给 B！
+
+这就是典型的**并发冲突**问题。
+
+### 5.1 什么是事务 (Transaction)？
+
+**事务**是数据库的一组操作，这些操作要么全部成功，要么全部失败，不会出现"做了一半"的情况。
+
+事务有四大特性，简称 **ACID**：
+
+| 特性 | 英文 | 含义 | 12306 的例子 |
+|------|------|------|--------------|
+| **A**tomicity | 原子性 | 操作要么全做，要么全不做 | 买票时扣款和出票必须同时成功，不能只扣钱不出票 |
+| **C**onsistency | 一致性 | 数据始终保持合法状态 | 票卖完了，库存必须是 0，不能是负数 |
+| **I**solation | 隔离性 | 多个事务互不影响 | A 在买票时，B 看到的结果应该是"已售罄"或"还剩 1 张"，不会看到中间状态 |
+| **D**urability | 持久性 | 一旦提交，数据永久保存 | 订单成功后，即使服务器宕机，已售出的票也不会丢失 |
+
+### 5.2 事务的隔离级别：鱼与熊掌的权衡
+
+理论上，我们希望事务完全隔离（最高的隔离性）。但在实际系统中，**完全隔离 = 性能极差**（因为需要大量加锁，其他事务只能等待）。
+
+因此，数据库提供了四种**隔离级别**，让开发者根据业务场景权衡：
+
+| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
+|----------|------|------------|------|----------|
+| **读未提交** | 可能 | 可能 | 可能 | 几乎不用（数据可能错误） |
+| **读已提交** | 不可能 | 可能 | 可能 | 普通业务（Oracle 默认） |
+| **可重复读** | 不可能 | 不可能 | 可能 | 银行转账（MySQL 默认） |
+| **串行化** | 不可能 | 不可能 | 不可能 | 极端严格场景（极少用） |
+
+**名词解释**：
+- **脏读**：读到了其他事务还没提交的数据（可能回滚）。
+- **不可重复读**：同一个事务里，两次读同一个数据，结果不一样（因为被其他事务修改了）。
+- **幻读**：同一个事务里，两次查询，结果集的行数不一样（因为其他事务插入或删除了数据）。
+
+<TransactionACIDDemo />
+
+---
+
+## 6. 性能优化：如何让你的查询快 1000 倍？
+
+现在你已经理解了索引、事务这些核心概念。但在真实项目中，你可能会遇到这样的问题：
+
+- "明明建了索引，为什么查询还是很慢？"
+- "这条 SQL 昨天还很快，今天怎么突然卡死了？"
+- "并发一高，数据库就挂了，怎么办？"
+
+本节将给出**可直接落地的优化策略**。
+
+### 6.1 索引使用避坑指南
+
+**坑 1：在索引列上使用函数，导致索引失效**
+
+```sql
+-- 错误：对索引列使用函数，无法使用索引
+SELECT * FROM users WHERE YEAR(created_at) = 2024;
+
+-- 正确：改写为范围查询，可以使用索引
+SELECT * FROM users WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';
+```
+
+**坑 2：隐式类型转换，导致索引失效**
+
+```sql
+-- 假设 user_id 是 int 类型
+-- 错误：传字符串，可能导致隐式转换
+SELECT * FROM users WHERE user_id = '123';
+
+-- 正确：传对应类型
+SELECT * FROM users WHERE user_id = 123;
+```
+
+**坑 3：LIKE 查询以 % 开头，无法使用索引**
+
+```sql
+-- 错误：以 % 开头，无法使用索引
+SELECT * FROM users WHERE name LIKE '%张三%';
+
+-- 正确：以固定前缀开头，可以使用索引
+SELECT * FROM users WHERE name LIKE '张三%';
+```
+
+### 6.2 SQL 优化技巧模板
+
+**模板 1：分页优化（深分页问题）**
+
+```sql
+-- 问题：当 OFFSET 很大时，查询会越来越慢
+SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 1000000;
+
+-- 优化方案 1：使用覆盖索引
+SELECT * FROM orders
+WHERE created_at < '上次查询的最小时间戳'
+ORDER BY created_at DESC LIMIT 10;
+
+-- 优化方案 2：使用主键范围查询
+SELECT * FROM orders
+WHERE order_id > 上次查询的最大order_id
+ORDER BY order_id LIMIT 10;
+```
+
+**模板 2：批量插入优化**
+
+```sql
+-- 低效：多次单条插入
+INSERT INTO users (name, age) VALUES ('张三', 25);
+INSERT INTO users (name, age) VALUES ('李四', 30);
+
+-- 高效：单条 SQL 批量插入
+INSERT INTO users (name, age) VALUES
+('张三', 25),
+('李四', 30),
+('王五', 28);
+```
+
+**模板 3：避免 SELECT **
+
+```sql
+-- 低效：返回所有列
+SELECT * FROM users WHERE user_id = 1;
+
+-- 高效：只返回需要的列
+SELECT user_id, name, email FROM users WHERE user_id = 1;
+```
+
+### 6.3 高并发场景应对策略
+
+| 场景 | 问题 | 解决方案 |
+|------|------|----------|
+| 热点数据 | 某行数据被频繁读写，导致锁竞争 | 缓存 + 读写分离；或分段锁 |
+| 秒杀场景 | 瞬间高并发扣减库存 | 乐观锁 + 库存预热 + 队列削峰 |
+| 慢查询 | 复杂查询拖垮数据库 | 索引优化 + 查询拆分 + 读写分离 |
+| 连接数耗尽 | 太多并发请求导致连接池耗尽 | 连接池优化 + 限流 + 服务降级 |
+
+<QueryOptimizationDemo />
+
+---
+
+## 7. 总结与学习路线

 现在你已经打通了从"Excel 表格"到"B+ 树索引"的任督二脉：

@@ -402,6 +553,8 @@ B+ 树有一个非常聪明的设计：**它非常"矮胖"**。
 2. **数据的组织**：通过**表**、**列**、**行**、**主键**组织数据，通过**关系**（外键）连接多张表，消除冗余。
 3. **SQL 语言**：使用 `SELECT`、`INSERT`、`UPDATE`、`DELETE` 等命令与数据库对话，通过 `JOIN` 实现多表查询。
 4. **索引原理**：使用 **B+ 树**作为底层数据结构，通过"矮胖"的树形结构，将磁盘 I/O 次数降至最低，实现毫秒级查询。
+5. **事务安全**：通过 **ACID 特性**和**隔离级别**，保证数据的一致性、完整性和并发安全。
+6. **性能优化**：通过合理的索引设计、SQL 优化和高并发策略，让查询效率提升 1000 倍。

 **下一步建议**：

@@ -411,7 +564,7 @@ B+ 树有一个非常聪明的设计：**它非常"矮胖"**。

 ---

-## 6. 名词速查表 (Glossary)
+## 8. 名词速查表 (Glossary)

 | 名词 | 英文 | 解释 |
 |------|------|------|
@@ -428,3 +581,9 @@ B+ 树有一个非常聪明的设计：**它非常"矮胖"**。
 | **B+ 树** | B+ Tree | 数据库索引常用的数据结构，具有矮胖、有序、支持范围查询的特点 |
 | **全表扫描** | Full Table Scan | 不通过索引，逐行扫描整张表的查询方式，效率低 |
 | **磁盘 I/O** | Disk I/O | 从磁盘读取或写入数据的操作，相对于内存操作非常慢 |
+| **事务** | Transaction | 一组数据库操作，要么全部成功，要么全部失败 |
+| **ACID** | Atomicity, Consistency, Isolation, Durability | 事务的四大特性：原子性、一致性、隔离性、持久性 |
+| **隔离级别** | Isolation Level | 事务并发时的隔离程度，分为读未提交、读已提交、可重复读、串行化 |
+| **脏读** | Dirty Read | 读到了其他事务未提交的数据 |
+| **不可重复读** | Non-repeatable Read | 同一事务内两次读取同一数据，结果不同 |
+| **幻读** | Phantom Read | 同一事务内两次查询，结果集的行数不同 |