feat: comprehensive documentation and demo updates
- Update READMEs and docs across multiple languages - Enhance interactive demos for Agent, LLM, VLM, Audio, Image Gen, Terminal, and Web Basics - Add new appendix sections for Database and IDE intros - Update VitePress config, theme, and utility scripts - Clean up unused assets and components
This commit is contained in:
@@ -0,0 +1,125 @@
|
||||
# 数据库原理入门:从 Excel 到 SQL
|
||||
|
||||
> 💡 **学习指南**:本章节无需计算机专业背景。我们将从你熟悉的 Excel 表格开始,一步步带你理解数据库(Database)的核心原理,并揭示它为什么能从数十亿条数据中瞬间找到你想要的那一条。
|
||||
|
||||
## 1. 数据的进化:为什么要用数据库?
|
||||
|
||||
想象一下,你经营着一家小书店。
|
||||
|
||||
### 第一阶段:记事本
|
||||
|
||||
刚开始,你每天卖出几本书,随手记在**记事本**上。
|
||||
|
||||
- _优点_:简单,拿笔就能写。
|
||||
- _缺点_:想知道“上个月一共卖了多少钱?”或者“哪本书卖得最好?”,你需要一页页翻,按着计算器算半天。
|
||||
|
||||
### 第二阶段:Excel 表格
|
||||
|
||||
生意好了,你开始用 **Excel**。
|
||||
你建了一张表,列出了:`书名`、`价格`、`购买者`、`日期`。
|
||||
|
||||
- _优点_:可以自动求和,可以排序,可以筛选。
|
||||
- _缺点_:
|
||||
- **容量有限**:当你有 100 万行数据时,Excel 打开都要几分钟,甚至直接卡死。
|
||||
- **难以协作**:你和店员不能同时修改同一个文件,否则会冲突。
|
||||
- **数据不安全**:不小心删了一行,可能很难找回来。
|
||||
|
||||
### 第三阶段:数据库 (Database)
|
||||
|
||||
当你的书店变成了“亚马逊”,你需要处理亿级的订单,成千上万的用户同时访问。这时,你就需要**数据库**。
|
||||
数据库,本质上就是一个**“超级 Excel”**,但它专为**海量数据**、**高并发访问**和**数据安全**而设计。
|
||||
|
||||
---
|
||||
|
||||
## 2. 数据库长什么样?
|
||||
|
||||
最流行的数据库类型是**关系型数据库 (Relational Database)**,比如 MySQL、PostgreSQL。它们的样子其实和 Excel 非常像。
|
||||
|
||||
### 核心概念
|
||||
|
||||
1. **表 (Table)**:就像 Excel 中的一个 Sheet。比如 `users`(用户表)、`orders`(订单表)。
|
||||
2. **列 (Column)**:数据的属性。比如 `name`(姓名)、`age`(年龄)。
|
||||
3. **行 (Row)**:一条具体的数据。比如“张三,25岁”就是一行。
|
||||
4. **主键 (Primary Key)**:每一行的唯一身份证号。通常是一个数字 ID(如 `user_id`),绝对不会重复。
|
||||
|
||||
### 关系 (Relation)
|
||||
|
||||
这是数据库比 Excel 强大的关键。
|
||||
Excel 里,你可能在订单表里重复写“张三”的地址和电话。
|
||||
数据库里,我们把数据拆开:
|
||||
|
||||
- **用户表**:只存用户 ID、姓名、电话。
|
||||
- **订单表**:只存订单号、书名、**用户 ID**。
|
||||
|
||||
当我们需要查看“某个订单是谁买的”时,数据库会通过 **用户 ID** 瞬间把两张表关联(Join)起来。这样做既节省空间,又保证了如果张三换了电话,只需要改用户表,所有订单显示的电话都会自动更新。
|
||||
|
||||
---
|
||||
|
||||
## 3. 如何和数据库说话?(SQL)
|
||||
|
||||
你不能直接用鼠标去点数据库,你需要用一种特殊的语言:**SQL (Structured Query Language)**。
|
||||
它读起来很像英语:
|
||||
|
||||
- **查数据 (Read)**:
|
||||
|
||||
```sql
|
||||
SELECT name, price FROM books WHERE price < 50;
|
||||
-- 翻译:从 books 表里,把价格小于 50 的书的名字和价格拿出来。
|
||||
```
|
||||
|
||||
- **改数据 (Update)**:
|
||||
```sql
|
||||
UPDATE users SET score = score + 10 WHERE id = 101;
|
||||
-- 翻译:把 ID 是 101 的用户,积分加 10 分。
|
||||
```
|
||||
|
||||
<ClientOnly>
|
||||
<SqlPlaygroundDemo />
|
||||
</ClientOnly>
|
||||
|
||||
---
|
||||
|
||||
## 4. 为什么数据库这么快?(索引原理)
|
||||
|
||||
这是数据库最神奇的地方。
|
||||
如果你在 Excel 里找“所有姓张的人”,Excel 可能需要从第一行扫到最后一行。
|
||||
但在数据库里,即使有 10 亿行数据,查找也只需要几毫秒。
|
||||
|
||||
**秘诀就是:索引 (Index)。**
|
||||
|
||||
### 4.1 直观演示:全表扫描 vs 索引查找
|
||||
|
||||
让我们通过一个交互演示来看看区别。
|
||||
假设我们要查找 `ID = 55` 的数据:
|
||||
|
||||
- **全表扫描 (Full Table Scan)**: 就像在图书馆找一本没编号的书,必须从头到尾一本一本看。数据越多,越慢。
|
||||
- **索引查找 (Index Search)**: 就像查字典,或者用二分法。因为数据已经排好序(建立了索引),我们可以迅速跳过无关数据,直奔目标。
|
||||
|
||||
<ClientOnly>
|
||||
<DatabaseIndexDemo />
|
||||
</ClientOnly>
|
||||
|
||||
::: tip 试一试
|
||||
在上面的演示中,点击 **“索引查找”**。你会发现查找次数极少。这就是为什么数据库能瞬间响应你的请求。
|
||||
:::
|
||||
|
||||
### 4.2 底层数据结构:B+ 树
|
||||
|
||||
真实数据库使用的索引结构叫 **B+ 树**。
|
||||
它像一棵倒过来的树,非常“矮胖”。
|
||||
|
||||
- **根节点**指引大方向。
|
||||
- **中间节点**指引小范围。
|
||||
- **叶子节点**存储真正的数据。
|
||||
|
||||
通常,一棵存储了 1 亿条数据的 B+ 树,高度只有 3 到 4 层。这意味着,数据库只需要读取 3 到 4 次磁盘,就能找到这 1 亿条数据中的任意一条!
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
|
||||
1. **数据库**是处理海量数据的“超级 Excel”。
|
||||
2. 我们用 **SQL** 语言来指挥数据库工作。
|
||||
3. **索引**(底层是 B+ 树)是数据库查询速度快如闪电的秘密武器。
|
||||
|
||||
现在,当你听到后端工程师说“我在查数据库”时,你的脑海里应该浮现出:他在写一句 SQL 指令,通过 B+ 树索引,在毫秒间从亿万数据中抓取到了用户想要的那一行。
|
||||
Reference in New Issue
Block a user