# 数据库原理入门：为什么淘宝能在 0.01 秒内找到你的订单？

> 💡 **学习指南**：本章节无需编程基础。我们将从一个你熟悉的场景出发——当你在淘宝搜索订单时，系统如何在 10 亿条记录中瞬间定位到你购买的那件 T 恤？答案藏在数据库的底层原理里：B+ 树、索引、事务……我们会用真实的业务案例（淘宝、微信、12306）一步步拆解这些概念。

---

## 0. 引言：当你的 Excel 打不开时

想象一下：

- **场景 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 当数据增长到 1 万条时：Excel 时代

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

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

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

**优点**：
- 可以**自动求和**（SUM 函数）。
- 可以**排序**（按价格从高到低）。
- 可以**筛选**（只看张三的购买记录）。

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

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

### 1.3 当数据达到 1 亿条时：数据库时代

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

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

**核心优势对比**：

| 特性 | 记事本 | Excel | 数据库 |
|------|--------|-------|--------|
| 数据量 | 极少 | 中等 (百万级) | 海量 (亿级+) |
| 并发访问 | 单人 | 单人/顺序 | 千人/万人在线 |
| 数据安全 | 低 | 中 | 高 (备份、事务) |
| 数据关系 | 无 | 弱 | 强 (关系型) |
| 查询速度 | 极慢 | 中等 | 极快 (毫秒级) |

---

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

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

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

想象你是一个**图书馆管理员**。

| 数据库概念 | 图书馆类比 | 解释 |
|------------|------------|------|
| **数据库 (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 永不重复）

<DatabaseRelationDemo />

### 2.2 关系 (Relation)：数据库的灵魂

这是数据库比 Excel 强大的关键。

**Excel 的问题：数据冗余**

在 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` 表一行，所有订单关联的电话自动更新。
- **灵活查询**：可以轻松回答复杂问题，比如"统计每个用户的总消费金额"。

---

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

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

这种语言就是 **SQL (Structured Query Language，结构化查询语言)**。

好消息是，SQL 非常接近自然英语，读起来就像一句话。

### 3.1 SQL 的核心命令：CRUD

大部分时候，你只需要掌握四种操作，江湖人称 **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 | 北京 |

**商品表 (products)**：

| product_id | name | price | stock |
|------------|------|-------|-------|
| 101 | iPhone 15 | 5999 | 1000 |
| 102 | MacBook Pro | 14999 | 500 |
| 103 | AirPods Pro | 1999 | 2000 |

#### 查询数据 (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**：查找价格在 5000 到 15000 之间的商品

```sql
SELECT name, price FROM products WHERE price BETWEEN 5000 AND 15000;
```

#### 插入数据 (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 | 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, p.name AS product_name, o.quantity, o.order_date
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN products p ON o.product_id = p.product_id
WHERE u.name = '张三';
```

**返回结果**：

| name | product_name | quantity | order_date |
|------|--------------|----------|------------|
| 张三 | iPhone 15 | 1 | 2024-01-15 |
| 张三 | AirPods Pro | 2 | 2024-01-16 |

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

<SqlPlaygroundDemo />

---

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

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

如果你在 Excel 里找"所有姓张的人"，Excel 可能需要从第一行扫到最后一行。这就是**全表扫描 (Full Table Scan)**——数据越多，速度越慢。

但在数据库里，即使有 10 亿行数据，查找也只需要几毫秒。

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

### 4.1 直观理解：字典的启示

想象你要在一本没有目录、没有页码的 1000 页书里找一个词。你该怎么办？

**只能一页一页翻**——这就是全表扫描。

但现在，你手里有一本**字典**。字典有一个按字母排序的**索引**。

你要找"数据库"这个词：
1. 翻到"数"字开头的区域（快速定位）。
2. 在"数"字区域内，按第二个字"据"的顺序找。
3. 很快，你就定位到了"数据库"这个词所在的页码。

这就是**索引查找**——不需要翻完整本书，只需要查索引，直接跳转到目标位置。

### 4.2 全表扫描 vs 索引查找

让我们通过一个具体的例子来感受两者的差异。

假设我们有一张用户表，里面有 1000 万条用户记录。

**场景：查找 ID = 5,555,555 的用户**

| 方式 | 过程 | 需要检查的行数 | 耗时（估算） |
|------|------|----------------|--------------|
| **全表扫描** | 从第 1 行开始，一行一行看，直到找到 ID = 5,555,555 | 平均 500 万行 | 数秒 ~ 数十秒 |
| **索引查找** | 查索引树，直接跳到目标位置 | 约 3-4 次比较 | 数毫秒 |

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

### 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. 事务：当多人同时抢票时，系统如何保证不重复售票？

想象一下春运期间的 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+ 树索引"的任督二脉：

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

**下一步建议**：

- 如果你想动手实践，可以尝试安装 **MySQL** 或 **PostgreSQL**，亲手创建几张表，插入数据，体验 SQL 的强大。
- 如果你对后端开发感兴趣，可以学习如何使用 **ORM**（如 SQLAlchemy、Prisma）在代码中操作数据库，而不需要手写 SQL。
- 如果你想深入底层，可以研究 **InnoDB 存储引擎**的原理，了解事务、锁、MVCC 等高级概念。

---

## 8. 名词速查表 (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 | 从磁盘读取或写入数据的操作，相对于内存操作非常慢 |
| **事务** | Transaction | 一组数据库操作，要么全部成功，要么全部失败 |
| **ACID** | Atomicity, Consistency, Isolation, Durability | 事务的四大特性：原子性、一致性、隔离性、持久性 |
| **隔离级别** | Isolation Level | 事务并发时的隔离程度，分为读未提交、读已提交、可重复读、串行化 |
| **脏读** | Dirty Read | 读到了其他事务未提交的数据 |
| **不可重复读** | Non-repeatable Read | 同一事务内两次读取同一数据，结果不同 |
| **幻读** | Phantom Read | 同一事务内两次查询，结果集的行数不同 |