feat(docs): add performance overview demo component and update content structure

- Create PerformanceOverviewDemo.vue with interactive performance dimension visualization - Update config.mjs to support new component registration - Add new frontend evolution components to theme/index.js - Consolidate stage-0 intro pages into index.md across all locales - Enhance LLM intro documentation with tokenization details
2026-02-05 01:33:28 +08:00
parent 3c4a5c0e0b
commit e8bba6f7c0
27 changed files with 4375 additions and 873 deletions
@@ -1,125 +1,430 @@
 # 数据库原理入门：从 Excel 到 SQL

-> 💡 **学习指南**：本章节无需计算机专业背景。我们将从你熟悉的 Excel 表格开始，一步步带你理解数据库（Database）的核心原理，并揭示它为什么能从数十亿条数据中瞬间找到你想要的那一条。
+> 💡 **学习指南**：本章节无需编程基础，我们将从你熟悉的 Excel 表格出发，一步步深入数据库的底层原理。你会明白为什么数据库能从数十亿条数据中瞬间找到你想要的那一条，以及它背后那个神奇的 B+ 树是如何工作的。

-## 1. 数据的进化：为什么要用数据库？
+<DatabaseQuickStartDemo />
+
+## 0. 引言：当数据像滚雪球一样增长
+
+人类天生擅长处理小数据。一家小店里的账目、一个班级里的学生名单，我们可以轻松地记在脑子里，或者写在纸上。
+
+但是，当数据开始**像滚雪球一样增长**时——从 100 条变成 100 万条，从 1 个用户变成 1 亿个用户——我们遇到了一个核心问题：
+
+**如何高效地存取海量数据？**
+
+这个问题的答案，就是**数据库 (Database)**。
+
+本教程将带你从零开始，一步步拆解数据库这座大厦的构建过程：
+
+1. **存储**：数据是如何从 Excel 进化到数据库的？
+2. **组织**：表、列、行、关系，这些概念到底是什么？
+3. **语言**：如何用 SQL 与数据库对话？
+4. **速度**：为什么数据库能毫秒级查询？（揭秘 B+ 树索引）
+
+---
+
+## 1. 数据的进化：从记事本到数据库

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

-### 第一阶段：记事本
+### 1.1 第一阶段：记事本

 刚开始，你每天卖出几本书，随手记在**记事本**上。

- _优点_：简单，拿笔就能写。
- _缺点_：想知道“上个月一共卖了多少钱？”或者“哪本书卖得最好？”，你需要一页页翻，按着计算器算半天。
+- **优点**：简单，拿笔就能写。
+- **缺点**：
+  - 想知道"上个月一共卖了多少钱？"——你得一页页翻，按着计算器算半天。
+  - 想知道"哪本书卖得最好？"——你可能需要手动数每本书出现的次数。

-### 第二阶段：Excel 表格
+这就是**无结构化数据**的困境：数据是死的，想要获得洞察，需要人工大量加工。
+
+### 1.2 第二阶段：Excel 表格

 生意好了，你开始用 **Excel**。
+
 你建了一张表，列出了：`书名`、`价格`、`购买者`、`日期`。

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

-### 第三阶段：数据库 (Database)
+这就是**单机文件型数据**的瓶颈：它只适合个人或小团队处理中等规模的数据。

-当你的书店变成了“亚马逊”，你需要处理亿级的订单，成千上万的用户同时访问。这时，你就需要**数据库**。
-数据库，本质上就是一个**“超级 Excel”**，但它专为**海量数据**、**高并发访问**和**数据安全**而设计。
+### 1.3 第三阶段：数据库 (Database)
+
+当你的书店变成了"亚马逊"，你需要处理亿级的订单，成千上万的用户同时访问。这时，你就需要**数据库**。
+
+**数据库，本质上就是一个"超级 Excel"**，但它专为**海量数据**、**高并发访问**和**数据安全**而设计。
+
+<DatabaseEvolutionDemo />
+
+**核心优势对比**：
+
+| 特性 | 记事本 | Excel | 数据库 |
+|------|--------|-------|--------|
+| 数据量 | 极少 | 中等 (百万级) | 海量 (亿级+) |
+| 并发访问 | 单人 | 单人/顺序 | 千人/万人在线 |
+| 数据安全 | 低 | 中 | 高 (备份、事务) |
+| 数据关系 | 无 | 弱 | 强 (关系型) |
+| 查询速度 | 极慢 | 中等 | 极快 (毫秒级) |

 ---

 ## 2. 数据库长什么样？

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

-### 核心概念
+### 2.1 核心概念：图书馆的比喻

-1.  **表 (Table)**：就像 Excel 中的一个 Sheet。比如 `users`（用户表）、`orders`（订单表）。
-2.  **列 (Column)**：数据的属性。比如 `name`（姓名）、`age`（年龄）。
-3.  **行 (Row)**：一条具体的数据。比如“张三，25岁”就是一行。
-4.  **主键 (Primary Key)**：每一行的唯一身份证号。通常是一个数字 ID（如 `user_id`），绝对不会重复。
+想象你是一个**图书馆管理员**。

-### 关系 (Relation)
+| 数据库概念 | 图书馆类比 | 解释 |
+|------------|------------|------|
+| **数据库 (Database)** | 整座图书馆 | 存放所有数据的容器 |
+| **表 (Table)** | 一个书架 | 存放同一类数据的集合，比如"用户书架"、"图书书架" |
+| **列 (Column)** | 书脊上的标签 | 数据的属性，比如"书名"、"作者"、"出版日期" |
+| **行 (Row)** | 书架上的每一本书 | 一条具体的数据记录，比如"《百年孤独》，马尔克斯，1967" |
+| **主键 (Primary Key)** | 每本书的 ISBN 编号 | 唯一标识每一行的 ID，绝对不会重复 |
+
+**举个例子**：
+
+**用户表 (users)**：
+
+| user_id (主键) | name | age | email |
+|----------------|------|-----|-------|
+| 1 | 张三 | 25 | zhangsan@example.com |
+| 2 | 李四 | 30 | lisi@example.com |
+| 3 | 王五 | 28 | wangwu@example.com |
+
+- **表**：`users`（用户书架）
+- **列**：`user_id`、`name`、`age`、`email`（书脊标签）
+- **行**：每一行是一个用户（书架上的每本书）
+- **主键**：`user_id`（ISBN 编号，1、2、3 永不重复）
+
+### 2.2 关系 (Relation)：数据库的灵魂

 这是数据库比 Excel 强大的关键。
-Excel 里，你可能在订单表里重复写“张三”的地址和电话。
-数据库里，我们把数据拆开：

- **用户表**：只存用户 ID、姓名、电话。
- **订单表**：只存订单号、书名、**用户 ID**。
+**Excel 的问题：数据冗余**

-当我们需要查看“某个订单是谁买的”时，数据库会通过 **用户 ID** 瞬间把两张表关联（Join）起来。这样做既节省空间，又保证了如果张三换了电话，只需要改用户表，所有订单显示的电话都会自动更新。
+在 Excel 中，如果你要记录订单，可能会这样写：
+
+| 订单号 | 书名 | 价格 | 购买者 | 购买者电话 | 购买者地址 |
+|--------|------|------|--------|------------|------------|
+| 001 | 百年孤独 | 59 | 张三 | 138xxxx | 北京 |
+| 002 | 活着 | 39 | 张三 | 138xxxx | 北京 |
+| 003 | 三体 | 99 | 张三 | 138xxxx | 北京 |
+
+**问题**：
+- 张三买了 100 本书，你得重复写 100 次他的电话和地址。
+- 如果张三换了电话，你得修改 100 行，漏改一行就数据不一致了。
+- 数据量爆炸，浪费存储空间。
+
+**数据库的解决方案：拆表 + 关联**
+
+数据库会把数据拆开，存到不同的表里，通过**关系**（外键）把它们连起来。
+
+**用户表 (users)**：
+
+| user_id (主键) | name | phone | address |
+|----------------|------|-------|---------|
+| 101 | 张三 | 138xxxx | 北京 |
+| 102 | 李四 | 139xxxx | 上海 |
+
+**订单表 (orders)**：
+
+| order_id (主键) | book_name | price | user_id (外键) |
+|-----------------|-----------|-------|----------------|
+| 001 | 百年孤独 | 59 | 101 |
+| 002 | 活着 | 39 | 101 |
+| 003 | 三体 | 99 | 101 |
+| 004 | 百年孤独 | 59 | 102 |
+
+**关系解释**：
+- `orders` 表里的 `user_id` 列，指向 `users` 表的 `user_id` 主键。
+- 当我们要查看"订单 001 是谁买的"时，数据库会去 `users` 表里查找 `user_id = 101` 的行，发现是"张三"。
+- 这种通过**外键 (Foreign Key)** 建立表与表之间联系的方式，就是**关系 (Relation)** 的含义。
+
+**好处**：
+- **节省空间**：张三的信息只存一次，不管他买多少本书。
+- **数据一致**：张三换电话，只需要改 `users` 表一行，所有订单关联的电话自动更新。
+- **灵活查询**：可以轻松回答复杂问题，比如"统计每个用户的总消费金额"。
+
+<DatabaseRelationDemo />

 ---

-## 3. 如何和数据库说话？(SQL)
+## 3. 如何和数据库说话？（SQL 入门）

-你不能直接用鼠标去点数据库，你需要用一种特殊的语言：**SQL (Structured Query Language)**。
-它读起来很像英语：
+你不能直接用鼠标去点数据库（虽然有图形化工具，但本质也是转换成命令），你需要用一种特殊的、标准化的语言来指挥数据库工作。

- **查数据 (Read)**:
+这种语言就是 **SQL (Structured Query Language，结构化查询语言)**。

-  ```sql
-  SELECT name, price FROM books WHERE price < 50;
-  -- 翻译：从 books 表里，把价格小于 50 的书的名字和价格拿出来。
-  ```
+好消息是，SQL 非常接近自然英语，读起来就像一句话。

- **改数据 (Update)**:
-  ```sql
-  UPDATE users SET score = score + 10 WHERE id = 101;
-  -- 翻译：把 ID 是 101 的用户，积分加 10 分。
-  ```
+### 3.1 SQL 的核心命令：CRUD

-<ClientOnly>
-  <SqlPlaygroundDemo />
-</ClientOnly>
+大部分时候，你只需要掌握四种操作，江湖人称 **CRUD**：
+
+| 操作 | 英文 | SQL 关键字 | 类比 Excel |
+|------|------|------------|------------|
+| **C**reate | 创建/插入 | `INSERT` | 在末尾新增一行 |
+| **R**ead | 读取/查询 | `SELECT` | 筛选、查找 |
+| **U**pdate | 更新/修改 | `UPDATE` | 修改单元格内容 |
+| **D**elete | 删除 | `DELETE` | 删除一行 |
+
+### 3.2 实战示例：书店管理系统
+
+假设我们有以下两张表：
+
+**用户表 (users)**：
+
+| user_id | name | age | city |
+|---------|------|-----|------|
+| 1 | 张三 | 25 | 北京 |
+| 2 | 李四 | 30 | 上海 |
+| 3 | 王五 | 28 | 北京 |
+
+**图书表 (books)**：
+
+| book_id | title | price | stock |
+|---------|-------|-------|-------|
+| 101 | 百年孤独 | 59 | 100 |
+| 102 | 活着 | 39 | 50 |
+| 103 | 三体 | 99 | 200 |
+
+#### 查询数据 (Read)
+
+**示例 1**：查找所有年龄大于 25 岁的用户
+
+```sql
+SELECT name, age FROM users WHERE age > 25;
+```
+
+**逐词翻译**：
+- `SELECT name, age`：选择 name 和 age 这两列
+- `FROM users`：从 users 这张表
+- `WHERE age > 25`：在 age 大于 25 的条件下
+
+**返回结果**：
+
+| name | age |
+|------|-----|
+| 李四 | 30 |
+| 王五 | 28 |
+
+**示例 2**：查找价格在 40 到 100 之间的图书
+
+```sql
+SELECT title, price FROM books WHERE price BETWEEN 40 AND 100;
+```
+
+#### 插入数据 (Create)
+
+**示例**：新增一个用户
+
+```sql
+INSERT INTO users (user_id, name, age, city)
+VALUES (4, '赵六', 35, '广州');
+```
+
+**逐词翻译**：
+- `INSERT INTO users`：插入到 users 表
+- `(user_id, name, age, city)`：这几列
+- `VALUES (4, '赵六', 35, '广州')`：值分别是...
+
+#### 更新数据 (Update)
+
+**示例**：给所有北京的用户年龄加 1 岁
+
+```sql
+UPDATE users
+SET age = age + 1
+WHERE city = '北京';
+```
+
+**⚠️ 重要警告**：如果你忘记写 `WHERE city = '北京'`，这条命令会把**所有用户**的年龄都加 1！在生产环境中，这是一个极其危险的错误。
+
+#### 删除数据 (Delete)
+
+**示例**：删除用户 ID 为 4 的用户
+
+```sql
+DELETE FROM users WHERE user_id = 4;
+```
+
+**⚠️ 重要警告**：和 UPDATE 一样，如果忘记写 `WHERE`，你会删除整张表的所有数据！这在生产环境中是灾难性的。
+
+### 3.3 多表查询：JOIN 的力量
+
+还记得我们讲过的"关系"吗？SQL 最强大的地方在于可以一次性查询多张关联的表。
+
+**示例场景**：查询"张三购买过的所有图书"
+
+假设我们还有一张订单表 (orders)：
+
+| order_id | user_id | book_id | quantity |
+|----------|---------|---------|----------|
+| 1001 | 1 | 101 | 1 |
+| 1002 | 1 | 102 | 2 |
+| 1003 | 2 | 101 | 1 |
+
+**SQL 查询**：
+
+```sql
+SELECT u.name, b.title, o.quantity
+FROM orders o
+JOIN users u ON o.user_id = u.user_id
+JOIN books b ON o.book_id = b.book_id
+WHERE u.name = '张三';
+```
+
+**返回结果**：
+
+| name | title | quantity |
+|------|-------|----------|
+| 张三 | 百年孤独 | 1 |
+| 张三 | 活着 | 2 |
+
+通过 `JOIN`，我们把三张表的数据关联在了一起，得到了完整的答案。
+
+<SqlPlaygroundDemo />

 ---

-## 4. 为什么数据库这么快？(索引原理)
+## 4. 为什么数据库这么快？（索引原理揭秘）
+
+这是数据库最神奇的地方，也是面试中最爱问的问题。
+
+如果你在 Excel 里找"所有姓张的人"，Excel 可能需要从第一行扫到最后一行。这就是**全表扫描 (Full Table Scan)**——数据越多，速度越慢。

-这是数据库最神奇的地方。
-如果你在 Excel 里找“所有姓张的人”，Excel 可能需要从第一行扫到最后一行。
 但在数据库里，即使有 10 亿行数据，查找也只需要几毫秒。

 **秘诀就是：索引 (Index)。**

-### 4.1 直观演示：全表扫描 vs 索引查找
+### 4.1 直观理解：字典的启示

-让我们通过一个交互演示来看看区别。
-假设我们要查找 `ID = 55` 的数据：
+想象你要在一本没有目录、没有页码的 1000 页书里找一个词。你该怎么办？

- **全表扫描 (Full Table Scan)**: 就像在图书馆找一本没编号的书，必须从头到尾一本一本看。数据越多，越慢。
- **索引查找 (Index Search)**: 就像查字典，或者用二分法。因为数据已经排好序（建立了索引），我们可以迅速跳过无关数据，直奔目标。
+**只能一页一页翻**——这就是全表扫描。

-<ClientOnly>
-  <DatabaseIndexDemo />
-</ClientOnly>
+但现在，你手里有一本**字典**。字典有一个按字母排序的**索引**。

-::: tip 试一试
-在上面的演示中，点击 **“索引查找”**。你会发现查找次数极少。这就是为什么数据库能瞬间响应你的请求。
-:::
+你要找"数据库"这个词：
+1. 翻到"数"字开头的区域（快速定位）。
+2. 在"数"字区域内，按第二个字"据"的顺序找。
+3. 很快，你就定位到了"数据库"这个词所在的页码。

-### 4.2 底层数据结构：B+ 树
+这就是**索引查找**——不需要翻完整本书，只需要查索引，直接跳转到目标位置。

-真实数据库使用的索引结构叫 **B+ 树**。
-它像一棵倒过来的树，非常“矮胖”。
+### 4.2 全表扫描 vs 索引查找

- **根节点**指引大方向。
- **中间节点**指引小范围。
- **叶子节点**存储真正的数据。
+让我们通过一个具体的例子来感受两者的差异。

-通常，一棵存储了 1 亿条数据的 B+ 树，高度只有 3 到 4 层。这意味着，数据库只需要读取 3 到 4 次磁盘，就能找到这 1 亿条数据中的任意一条！
+假设我们有一张用户表，里面有 1000 万条用户记录。
+
+**场景：查找 ID = 5,555,555 的用户**
+
+| 方式 | 过程 | 需要检查的行数 | 耗时（估算） |
+|------|------|----------------|--------------|
+| **全表扫描** | 从第 1 行开始，一行一行看，直到找到 ID = 5,555,555 | 平均 500 万行 | 数秒 ~ 数十秒 |
+| **索引查找** | 查索引树，直接跳到目标位置 | 约 3-4 次比较 | 数毫秒 |
+
+**速度差距**：数千倍甚至数万倍！
+
+<DatabaseIndexDemo />
+
+### 4.3 底层数据结构：B+ 树
+
+真实的索引并不是简单的"字母排序列表"，而是一种精心设计的数据结构，叫做 **B+ 树 (B+ Tree)**。
+
+#### 为什么是"树"？
+
+想象一棵倒过来的树：
+- **根节点 (Root)**：在最顶层，像树干。
+- **中间节点 (Internal Nodes)**：在树干和树叶之间，像树枝。
+- **叶子节点 (Leaf Nodes)**：在最底层，像树叶，存储着真正的数据或数据地址。
+
+#### B+ 树的特点：矮胖
+
+B+ 树有一个非常聪明的设计：**它非常"矮胖"**。
+
+- **矮**：从根到叶子，通常只有 3-4 层。
+- **胖**：每个节点可以存储很多个键值（比如几百个）。
+
+**为什么要"矮胖"？**
+
+因为数据库的数据最终是存储在**磁盘**（硬盘或 SSD）上的。
+
+每次从磁盘读取数据都需要**一次 I/O 操作**（磁盘寻道），这个操作相对于内存计算来说，非常**慢**（慢几千倍）。
+
+所以，B+ 树的设计目标是：**尽量减少磁盘 I/O 次数**。
+
+- **矮**：只有 3-4 层，意味着最多只需要 3-4 次磁盘读取就能找到数据。
+- **胖**：每一层能容纳大量数据，保证树不会变高。
+
+**实际例子**：
+
+假设一棵 B+ 树的每个节点可以存储 1000 个键值：
+
+- 根节点：1000 个键值 → 指向 1000 个中间节点
+- 中间节点：每个存 1000 个键值 → 指向 1000 个叶子节点
+- 叶子节点：每个存 1000 条真实数据
+
+**总数据量** = 1000 × 1000 × 1000 = **10 亿条数据**
+
+**树的高度** = **3 层**
+
+这意味着，在一个存储了 10 亿条数据的 B+ 树索引中，找到任意一条数据，**只需要 3 次磁盘 I/O**！
+
+这就是数据库查询飞快的秘密。
+
+<BPlusTreeDemo />

 ---

-## 5. 总结
+## 5. 总结与学习路线

-1.  **数据库**是处理海量数据的“超级 Excel”。
-2.  我们用 **SQL** 语言来指挥数据库工作。
-3.  **索引**（底层是 B+ 树）是数据库查询速度快如闪电的秘密武器。
+现在你已经打通了从"Excel 表格"到"B+ 树索引"的任督二脉：

-现在，当你听到后端工程师说“我在查数据库”时，你的脑海里应该浮现出：他在写一句 SQL 指令，通过 B+ 树索引，在毫秒间从亿万数据中抓取到了用户想要的那一行。
+1. **数据库的本质**：处理海量数据的"超级 Excel"，专为高并发、高安全、高性能而设计。
+2. **数据的组织**：通过**表**、**列**、**行**、**主键**组织数据，通过**关系**（外键）连接多张表，消除冗余。
+3. **SQL 语言**：使用 `SELECT`、`INSERT`、`UPDATE`、`DELETE` 等命令与数据库对话，通过 `JOIN` 实现多表查询。
+4. **索引原理**：使用 **B+ 树**作为底层数据结构，通过"矮胖"的树形结构，将磁盘 I/O 次数降至最低，实现毫秒级查询。
+
+**下一步建议**：
+
+- 如果你想动手实践，可以尝试安装 **MySQL** 或 **PostgreSQL**，亲手创建几张表，插入数据，体验 SQL 的强大。
+- 如果你对后端开发感兴趣，可以学习如何使用 **ORM**（如 SQLAlchemy、Prisma）在代码中操作数据库，而不需要手写 SQL。
+- 如果你想深入底层，可以研究 **InnoDB 存储引擎**的原理，了解事务、锁、MVCC 等高级概念。
+
+---
+
+## 6. 名词速查表 (Glossary)
+
+| 名词 | 英文 | 解释 |
+|------|------|------|
+| **数据库** | Database | 存储和管理数据的系统，专为海量数据、高并发访问而设计 |
+| **关系型数据库** | Relational Database | 基于关系模型组织数据的数据库，如 MySQL、PostgreSQL |
+| **表** | Table | 数据库中存储同一类数据的集合，由行和列组成 |
+| **列** | Column | 表的垂直维度，代表数据的一个属性（如"姓名"、"年龄"） |
+| **行** | Row | 表的水平维度，代表一条具体的数据记录 |
+| **主键** | Primary Key | 唯一标识表中每一行的列，值不能重复 |
+| **外键** | Foreign Key | 建立表与表之间关联的列，指向另一张表的主键 |
+| **关系** | Relation | 表与表之间通过主键和外键建立的关联 |
+| **SQL** | Structured Query Language | 结构化查询语言，用于与数据库通信的标准语言 |
+| **索引** | Index | 加速数据查询的数据结构，类似于书的目录 |
+| **B+ 树** | B+ Tree | 数据库索引常用的数据结构，具有矮胖、有序、支持范围查询的特点 |
+| **全表扫描** | Full Table Scan | 不通过索引，逐行扫描整张表的查询方式，效率低 |
+| **磁盘 I/O** | Disk I/O | 从磁盘读取或写入数据的操作，相对于内存操作非常慢 |