【数据库导学】

数据库导学

0. 这份文档的定位

这不是一份 SQL 语法手册，也不是一份数据库大全。

这份文档只做一件事：

• 帮你先建立数据库的整体地图

也就是说，它重点回答的是：

• 为什么会有这个知识点
• 这个知识点在解决什么问题
• 为什么要学它
• 它和前后知识点是什么关系

等这张地图先搭起来之后，你再去离散地学 SQL、索引、事务、ER 图、数据库设计，就不会学成一堆孤立名词。

1. 为什么会有数据库

学习数据库，第一步不是背术语，而是先回答：

• 为什么现实系统会需要数据库

如果没有数据库，最直觉的做法可能是：

• 把数据写进文本文件
• 或者先放进 Excel

在数据很少的时候，这样可以工作；但数据一多，问题就会出来：

• 不好查找
• 不好统计
• 不好多人一起改
• 不好保证格式统一
• 不好维护不同数据之间的关系
• 不好保证程序出错时数据仍然正确

所以数据库出现，是因为现实系统不仅要"把数据存下来"，还要解决这些更大的问题：

• 有组织地存
• 高效地查
• 安全地改
• 让多份数据能关联起来
• 尽量保证数据前后一致

简单说：

• 数据库是专门用来管理数据的系统，不是普通文件。

2. 数据库里的数据先怎么组织起来

知道为什么需要数据库之后，下一个问题就是：

• 这些数据在数据库里到底是怎么被组织起来的

2.1 为什么先从"表"讲起

入门时最常听到的是：

• 数据库
• 表
• 字段
• 记录

这是因为对初学者来说，"把数据先想成一张张表"最直观。

例如学校系统里会有：

• 学生信息
• 课程信息
• 成绩信息

最自然的组织方式就是：

• 先有一个数据库
• 再把不同类型的数据放到不同表里
• 每张表再定义清楚有哪些字段
• 每一行记录表示一个具体对象的数据

所以最基础的层次可以先记成：

数据库
-> 表
-> 字段（列）
-> 记录（行）

2.2 这套"表"的方式在解决什么问题

这套方式的价值在于：

• 先把不同类型的数据分开
• 再把每类数据的属性规定清楚
• 让数据后面更容易查询、修改、统计和关联

所以学"表、字段、记录"，不是为了背名词，而是在建立一种最常见的数据组织方式。

2.3 为什么还要知道不只有"表"这一种方式

虽然入门通常先从表开始，但这里必须马上补一句：

• 不是所有数据，都天然最适合用表格方式存储

有些数据很规整，适合用表：

• 用户信息
• 订单信息
• 成绩信息

但有些数据更适合别的组织方式：

• 缓存数据
• 结构经常变化的文档数据
• 关系特别复杂的网络关系数据

所以这里要先建立一个更大的认识：

• 有的数据适合用表组织
• 有的数据适合用键值对组织
• 有的数据适合用文档组织
• 有的数据适合用图结构组织

也就是说，讨论数据库时，要把这几个问题分开看：

• 数据怎么组织
• 数据主要放在哪里
• 数据是不是要长期保存

2.4 为什么会有关系型数据库和非关系型数据库

当你开始意识到"数据不一定都适合用表存"时，就自然会遇到两个大类：

• 关系型数据库
• 非关系型数据库

关系型数据库的核心特点是：

• 用表来组织数据
• 用行和列描述数据
• 通常用 SQL 操作

像 MySQL、MariaDB、PostgreSQL、SQLite 都属于这一类。

之所以入门先学它，是因为：

• 结构最直观
• 基础概念最完整
• 后面学主键、外键、约束、事务时更顺

非关系型数据库的核心特点是：

• 不以关系表模型作为核心
• 会按场景使用别的数据组织方式

常见例子有：

• Redis：键值型
• MongoDB：文档型
• Neo4j：图数据库

所以这一章真正想让你知道的是：

• 表是最常见的起点，但数据库世界不只有表。

3. 为什么还要学习 SQL

当你知道数据库里有表之后，下一个问题一定会出现：

• 数据放进去了，那我怎么查、怎么加、怎么改、怎么删

在关系型数据库这条主线上，这就是 SQL 出现的原因。

这里先补一个边界：

• 不是所有数据库都主要靠 SQL 操作
• 但关系型数据库通常会把 SQL 作为核心操作语言

所以这一章讨论 SQL，主要是在顺着"表模型"这条入门主线往下走。

SQL 的作用，不是单纯"写几条语句"，而是在解决：

• 如何用统一的方式和关系型数据库交互

如果没有这样一套统一语言，就会有很多问题：

• 操作不统一
• 程序不好和数据库配合
• 复杂查询不好表达
• 权限和约束也不好管理

所以学习 SQL，是因为关系型数据库通常需要这样一套相对统一的操作语言。

这里你先知道两件事就够了：

• 在关系型数据库里，SQL 是你和数据库"说话"的语言
• 它最常做的是增删改查

常见的对应关系是：

• SELECT：查
• INSERT：增
• UPDATE：改
• DELETE：删

为什么要学它：

• 因为后面所有实际操作，几乎都会回到"怎么用语言表达我要的数据"这个问题上

4. 为什么表里不能乱存数据

有了表和 SQL 之后，又会暴露一个新问题：

• 如果什么值都能往里塞，表很快就会乱掉

例如：

• 年龄有人写整数，有人写字符串
• 学号有人重复
• 某些关键字段被留空

这时数据库就不只是"存东西"，还要开始管规则。

所以这一步会自然引出三个知识点：

• 数据类型
• 约束
• 主键

4.1 为什么要有数据类型

数据类型是在解决：

• 这列数据本来应该是什么性质

例如：

• 年龄更适合整数
• 姓名更适合字符串
• 时间更适合日期时间类型

为什么要学：

• 因为它会直接影响存储、比较、排序和计算

4.2 为什么要有约束

约束是在解决：

• 明显不合法的数据，最好在进入表之前就被挡住

最常见的约束包括：

• NOT NULL
• UNIQUE
• DEFAULT

为什么要学：

• 因为很多数据错误，越早拦住越便宜

4.3 为什么要有主键

主键是在解决：

• 每条记录都必须能被唯一识别

如果没有主键，后面很多操作会变得模糊：

• 改谁
• 删谁
• 引用谁

为什么要学：

• 因为后面学外键、索引、表关系时，主键几乎都会参与进来

5. 为什么表和表之间还会有关联

现实里的数据通常不是孤立的。

例如：

• 一个学生会有多条成绩
• 一门课程会被很多学生选择

这时新的问题就出现了：

• 数据不能全塞进一张大表
• 但拆开之后，表和表之间又得重新连起来

所以这一章背后的问题其实是：

• 数据拆开后，关系怎么保留

这会自然引出两个知识点：

• 拆表
• 外键

为什么要拆表：

• 减少重复
• 降低修改出错概率
• 让结构更清楚

为什么要学外键：

• 因为它能把"这条数据属于谁"这种关系表达清楚
• 还能防止引用到根本不存在的数据

简单说：

• 拆表是在解决混乱，外键是在解决拆开之后怎么重新建立联系。

6. 为什么会有索引

当前面这些问题都解决之后，数据库还会遇到另一个很现实的问题：

• 数据一多，查询开始变慢

表里只有几条、几十条数据时，很多问题感觉不到。

但如果数据上万、几十万、上百万，数据库如果每次都从头扫到尾，成本就会越来越高。

所以索引出现，是因为要解决：

• 怎么更快定位到目标数据

6.1 索引在做什么

你可以先把索引理解成"目录"。

• 表更像正文
• 索引更像目录

它不是普通业务数据，而是数据库为了加快查找，额外维护的辅助结构。

为什么要学：

• 因为后面只要一涉及查询性能，就一定会碰到索引

6.2 索引是不是要单独建

有些索引会自动有，例如：

• 主键索引
• 唯一约束对应的索引

也有些索引需要你显式创建，例如：

CREATE INDEX idx_students_name ON students(name);

这不是再建一张普通表，而是让数据库内部维护一套更方便查找的结构。

6.3 为什么可视化工具里看不到索引"长什么样"

因为工具通常展示的是：

• 索引名
• 索引对应哪些列
• 它是主键、唯一索引还是普通索引

而不是把底层结构一条条摊开给你看。

为什么要知道这一点：

• 这样你就不会误以为"我没看到索引表，所以索引不存在"

6.4 为什么索引不是越多越好

索引能让查找更快，但会带来代价：

• 占空间
• 插入变慢
• 更新变慢
• 删除时也要维护

所以索引本质上是在做一种交换：

• 用额外维护成本，换更快的查询速度

为什么要学：

• 因为索引不是"能建就全建"，它是数据库性能设计的一部分

7. 为什么还要学事务

继续往工程里走，还会出现一种更严重的问题：

• 不是查得慢，而是数据可能会错

最典型的例子就是转账：

1. 从 A 扣钱
2. 给 B 加钱

如果第一步成功，第二步失败，系统就会进入错误状态。

所以事务出现，是因为要解决：

• 多个操作必须作为一个整体来保证正确

简单说，事务要求的是：

• 要么都成功
• 要么都失败回滚

为什么要学：

• 因为数据库不只是负责"存数据"，还要尽量保证关键操作前后一致

8. 为什么还要学 ER 图和数据库设计

当你已经知道表、主键、外键、索引、事务之后，还会遇到更上层的问题：

• 这些表到底该怎么设计出来
• 表和表之间的关系，一开始怎么想清楚

这时候就会自然引出两个知识点：

• ER图
• 数据库设计

8.1 为什么会先有 ER 图

如果一开始就直接建表，常常会乱，因为你还没想清楚：

• 系统里有哪些核心对象
• 谁和谁有关联
• 是一对一、一对多，还是多对多

ER图 的作用，就是先把这些关系画清楚。

它更偏概念层，主要回答：

• 有哪些数据对象
• 它们之间怎么联系

为什么要学：

• 因为它能帮你在建表之前先把关系理顺

8.2 为什么有了 ER 图还不够

ER图 只是把关系理清楚，还没有真正把数据库建出来。

真正落库时，还要继续决定：

• 建几张表
• 每张表有哪些字段
• 主键怎么定
• 外键怎么连
• 哪些字段要加约束
• 哪些字段以后可能要加索引

这一步才叫数据库设计。

所以两者的关系可以先记成：

• ER图：先理关系
• 数据库设计：再落表结构

为什么要学数据库设计：

• 因为表结构会直接影响正确性、可维护性和性能

9. 一条总主线

把前面的内容压成一条线，就是：

现实系统会产生很多数据
-> 普通文件和 Excel 不够用
-> 所以需要数据库
-> 数据需要先被组织起来
-> 最常见的入门方式是表、字段、记录
-> 但数据库不只有表模型
-> 有了表之后，需要 SQL 来操作数据
-> 有了数据之后，需要类型、约束、主键来保证规则
-> 数据拆开后，需要外键来保持关系
-> 数据一多后，需要索引来解决查找效率
-> 多步骤操作时，需要事务来保证正确性
-> 真正做系统时，还要先理关系，再做数据库设计

10. 后续可以离散地学什么

这份文档看到这里，你就已经有了一张数据库地图。

后面不一定要线性学到底，可以按兴趣或需求离散地学：

10.1 如果想先学实际操作

• SQL 基础
• 建库和建表
• 增删改查

10.2 如果想先学数据结构和关系

• 主键
• 外键
• 一对一、一对多、多对多
• ER 图
• 数据库设计

10.3 如果想先学性能

• 索引
• 慢查询
• 执行计划

10.4 如果想先学一致性

• 事务
• 回滚
• 隔离级别
• 锁

10.5 如果想先学数据库类型

• 关系型数据库
• 非关系型数据库
• Redis
• MongoDB

11. 建议学习顺序

如果你想按一条主线走，建议顺序是：

1. 为什么需要数据库
2. 数据是怎么组织起来的
3. 为什么要学 SQL
4. 为什么要有类型、约束、主键
5. 为什么会有表关系和外键
6. 为什么会有索引
7. 为什么会有事务
8. 为什么先理关系，再做数据库设计

12. 最后一句话

这份导学最想让你记住的是：

• 数据库不是一堆零散术语，而是一整条从"管理数据"走到"保证正确、效率和结构"的问题链。