带过几个刚学完数据库基础篇的同学，SQL语句写得挺顺，一问他“WHERE条件里拿字段跟空值做等值比较，为什么一行都查不出来”，就卡住了；再问“这张表到底该拆成几张”，基本靠感觉。这就是基础篇最容易出现的问题：概念全背过，一到要解释“为什么是这样”就断线。我后来发现，问题不出在知识点本身，而出在笔记的组织方式——大部分人是照着课本目录抄了一遍，概念之间没有钩子，考完就散。
这篇讲的就是怎么把数据库系统概论的基础篇重新捋成一份“能带走”的笔记。它不讲考试技巧，讲的是把这些看起来零散的概念串成一条线：三级模式为什么要这么分、关系模型到底约束了什么、SQL 的执行顺序为什么和书写顺序不一样、范式判定为什么必须按顺序走、事务的四个特性各自对应数据库内部的哪个零件。适合正在学这门课、刚入行做后端或者数据相关工作的朋友，也适合工作几年但一直靠“经验手感”写SQL、想补一次底层认知的人。我按自己整理笔记的实际顺序写，中间会把踩过的坑和后来才想明白的地方都摊开说。
1. 基础篇的笔记不能照目录抄，先钉死“三级模式”这根桩
我见过太多笔记是“第一章绪论：数据、数据库、DBMS、DBS 的区别”这样开头的，抄完一整页名词解释，实际上脑子里没有任何结构。基础篇真正的骨架是三级模式与两级映像，其他所有概念都挂在这根桩上。你在这张图上多花半小时，后面关系模型、视图、数据独立性、甚至事务隔离，都能顺下来。
1.1 外模式、模式、内模式到底是什么关系
用一句话概括：模式是“数据库里有什么”的全集，外模式是“某个用户能看见哪一块”，内模式是“这些数据在磁盘上怎么摆”。模式只有一，外模式可以有多个，内模式也只有一。这个“一与多”的关系是笔记里必须标出来的，因为它直接决定了后面两级映像的作用。
我习惯这样记：模式站在中间，往上看是“面向应用”，往下看是“面向存储”。学生最常混的是“模式”和“内模式”，因为很多教材举例时省掉了存储细节。你只要记住：模式描述的是逻辑结构（有哪些表、有哪些字段、什么类型），内模式描述的是物理结构（是顺序存储还是索引组织、有没有建聚簇、块大小多少）。一个只关心“有哪些表”，一个只关心“数据落在哪”。
这里补一个理解上的补充：模式是相对稳定的，内模式会随着性能优化不断变。你把一个字段从普通存储改成带索引，改的是内模式；你在模式上无感知。反过来，你给表加一个字段，改的是模式，所有引用这张表的外模式都可能要跟着调整。这个“哪一层动、哪一层不动”的判断，是后面数据独立性的前提。
1.2 两级映像和两种数据独立性，是一条因果链
笔记里我会把它写成两行对照，不让它散在正文里：
| 映像 | 位置 | 解决的问题 | 对应的独立性 |
|---|---|---|---|
| 外模式/模式映像 | 外模式与模式之间 | 模式变了，只要调整映像，外模式和应用程序不用改 | 逻辑独立性 |
| 模式/内模式映像 | 模式与内模式之间 | 内模式变了，只要调整映像，模式和应用程序不用改 | 物理独立性 |
关键不是背下这张表，而是理解为什么叫“独立性”。它指的是“应用不用改”。逻辑独立性说的是：数据库的逻辑结构变了（比如表拆分、加字段），只要这个应用的视图定义不变，代码就照跑；物理独立性说的是：存储方式变了（换索引、换存储组织），逻辑结构不动，代码照跑。这其实就是分层解耦的思路，和软件工程里的接口隔离是一个道理。
我当时的做法是：在这张表下面用一句话写下“以后看到视图，就往第一行靠；看到索引，就往第二行靠”。这个钩子非常好用，因为视图就是外模式的一个典型实现——你在视图上做查询，底层表怎么改，只要视图定义不改，上层无感。
1.3 为什么“数据与程序的独立性”是整门课的起点
这门课如果只让你带走一个观念，我建议是这个。早期的文件系统里，数据的存储结构一变，读数据的程序就得重写，改一次成本极高。数据库能取代文件系统，核心卖点不是“能存更多数据”，而是把数据的逻辑视图和物理存储切开了。这件事听起来抽象，但你实际做项目时天天在用它：你给某张表加了个联合索引，查询代码一行没改，速度从三秒变三十毫秒——这就是物理独立性在起效。
还有一个容易被忽略的点：DBMS 的职责清单其实也是围绕这层解耦展开的。数据定义、数据组织存储管理、数据操纵、事务管理与运行管理、建立与维护数据库，这五条职责你逐条对一遍，会发现每一条都是在替应用挡掉某一层的复杂性。定义挡的是“结构描述”，组织存储挡的是“物理布局”，操纵挡的是“怎么找到数据”，事务管理挡的是“并发和故障”，维护挡的是“备份恢复和性能”。这样记，就不是五个孤立的名词了。
2. 关系模型这一章其实只需要记四件事
很多人把关系模型那一章当成数学课来学，各种定义符号抄了满满几页，结果一遇到题还是不会判码。我的经验是：这一章能落地的只有四件事——关系是什么、码怎么判、完整性约束怎么用、关系代数怎么推。前两件决定你建表建得对不对，后两件决定你查询写得对不对。
2.1 码的判定有固定套路，不要靠看
候选码、主码、外码、全码这几个概念，初学者往往靠“看哪个字段像唯一标识”来判断，这在简单表上能蒙对，稍微复杂一点就翻车。正确做法是闭包法：给定属性集 U 和函数依赖集 F，对某个属性组合 X，求它在 F 下的闭包 X⁺，如果 X⁺ 包含了 U 的全部属性，且 X 的任何真子集都不行，那 X 就是候选码。
举个具体例子。R(A, B, C, D)，F = {A→B, B→C, C→D}。先看 A 的闭包：A 能推出 B，B 能推出 C，C 能推出 D，所以 A⁺ = ABCD，等于全集，且 A 是单属性没有真子集，所以 A 是候选码。再看 B⁺ = BCD，缺 A，不行；C⁺ = CD，不行；D⁺ = D，不行。所以这张表只有一个候选码 A，它就是主码。这种“从单属性开始逐个求闭包”的习惯，一定要在笔记里固化成流程，最好画成一个可以反复套用的三步：列属性、算闭包、查最小性。
再看一个多属性的情形。R(A, B, C)，F = {AB→C, C→A}。AB⁺ = ABC，所以 AB 是候选码；C⁺ = CA，加上 B 才能覆盖全体？注意 C⁺ = {C, A}，不等于全集，那 C 就不是候选码。但 BC 呢？BC⁺ = BCA = ABC，且 B⁺ = B、C⁺ = CA 都不够，所以 BC 也是候选码。这张表有两个候选码 AB 和 BC，主属性是 A、B、C 全部，非主属性为空。这个结论很关键，后面判范式时要用到——非主属性为空的关系，天然满足 3NF 和 BCNF，这个结论很多人不知道，白白多推半天。
2.2 三类完整性约束的易错点集中在“谁来保证”
实体完整性、参照完整性、用户定义完整性，这三条背起来很容易，但笔记里一定要写清楚每一条是在什么时候、由谁检查的。实体完整性要求主码非空且唯一，它在插入和更新时检查；参照完整性要求外码要么为空，要么等于被参照表里某个已存在的主码值，它同样在插入更新时检查，而且删除被参照行时也要检查；用户定义完整性就是那些业务规则，比如“年龄必须在 0 到 150 之间”。
初学者最容易搞错的是参照完整性里“外码可以为空”这一条。它不是绝对的，取决于业务语义。比如“员工表的部门编号”这个外码，如果允许“暂时未分配部门”，那它就能为空；如果业务上规定每个员工必须归属一个部门，那这个外码就得加非空约束。这个判断不是数据库能替你做的，必须写进笔记的业务规则里。
还有一个实操细节值得单独记一笔：级联删除和拒绝删除的选择。当被参照表的一行被删掉时，参照表里对应的行怎么办？可以选择级联删除（一起删）、置空（把外码设为空）、或者拒绝（报错）。这三种策略在实际系统里选错，轻则数据不一致，重则造成大范围误删。我一般的判断依据是：这个从属关系是不是“存在依赖”——订单和订单明细，订单没了明细就没意义，用级联；部门和员工，部门撤了员工还在，用置空或拒绝。
2.3 关系代数的五个基本运算要能互相推出来
关系代数最容易背成一锅粥，其实标准里只定义了五个基本运算：并、差、笛卡尔积、选择、投影。其他所有运算——交、连接、除——都是可以推出来的。笔记里必须明确标出这个层级，否则你会把八个运算平铺着背，考试一变形就不会。
并、差要求两个关系同元且对应属性来自同一域，这是很多人忽略的前提。笛卡尔积把两个关系拼起来，结果是元组数相乘，属性数相加。选择是从行上筛，投影是从列上取并去重——注意投影会自动去重，这一点和 SQL 里的 SELECT 不一样，SQL 的 SELECT 默认不去重，要加 DISTINCT。这个差异必须单独记。
交可以用差表示：R ∩ S = R − (R − S)。连接可以用笛卡尔积加选择表示：R ⋈ S = σ(条件)(R × S)。这样一写，你就不用单独记“交的规则是什么、连接的规则是什么”，只需要记“它们是怎么由基本运算拼出来的”。
2.4 除运算为什么要单独拎出来讲
除运算的语义是“对所有满足条件的，都要满足”。经典例子是“查询选修了全部课程的学生”。它在关系代数里是唯一一个带“全称”语义的运算，用其他运算符很难直接表达。笔记里我会把除运算的判定方法写成一个固定套路：设 R(X, Y) 和 S(Y)，R ÷ S 得到的是 X 上那些“与 S 中所有 Y 值组合都在 R 中出现”的值。
手算的方法是这样：先求 R 在 X 上的投影，得到候选集合；再对每个候选值 x，求它在 R 中对应的 Y 集合；如果这个 Y 集合包含了 S 的全部 Y 值，x 就保留。用这个流程手推一遍，比背定义有用得多。很多人卡在“为什么要先投影”，其实是因为除运算的结果只关心 X，Y 只是判断条件。
3. SQL 部分：从“能跑”到“知道为什么这么跑”
SQL 是基础篇里唯一能立刻上手练的部分，也是最容易产生“假会”的部分。语法背得熟、简单查询写得出来，不代表理解它的执行模型。我后来做优化相关的工作，发现大量慢查询的根因都是写的人不知道语句的真实执行顺序。
3.1 书写顺序和执行顺序是两码事
初学者写 SQL 是按“SELECT … FROM … WHERE … GROUP BY … HAVING … ORDER BY”这个书写顺序顺着想的，但数据库的逻辑执行顺序是：
FROM → ON → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT
这个顺序解释了非常多“反直觉”的现象。比如，为什么 WHERE 里不能用 SELECT 里定义的别名？因为 WHERE 执行的时候，SELECT 还没跑，别名还不存在。为什么 GROUP BY 之后只能选分组列和聚合函数？因为此时行已经被压缩成组，单行的字段值没有意义了。为什么 HAVING 能用聚合函数而 WHERE 不能？因为 WHERE 在分组之前执行，那时候还没有“组”。
我在笔记里会把这条顺序写成一条竖线，然后在每个箭头旁边标注“此时能访问什么”。这个方法比背结论有效得多，因为你一旦记住顺序，所有“为什么不能”都能自己推出来。
3.2 空值：三值逻辑是整个 SQL 最反直觉的设计
这一条我单独拿出来讲，因为它几乎每个新手都会栽。SQL 里的比较不是二值的，是三值：真、假、未知。任何跟 NULL 做的算术、比较、字符串拼接，结果都是未知。而 WHERE 子句只保留结果为“真”的行，所以WHERE 字段 = NULL永远查不出东西，必须写WHERE 字段 IS NULL。
更坑的是逻辑运算的组合规则。NULL = NULL的结果是未知，不是真。NOT (未知)还是未知。真 OR 未知是真，假 AND 未知是假。这四个组合规则记不住，你就永远搞不清为什么某些查询的结果行数对不上。
还有聚合函数对 NULL 的处理：COUNT(*) 统计所有行，COUNT(字段) 只统计该字段非空的行，SUM、AVG 会自动忽略 NULL。AVG 这一点尤其容易出错——如果一列有 10 行，其中 3 行是 NULL，AVG 的分母是 7 不是 10。如果你的统计口径要求 NULL 当 0 处理，就必须显式写 COALESCE 或者 CASE WHEN。
3.3 视图不只是“简化查询”
大部分人对视图的理解停留在“把一段复杂 SQL 存起来方便复用”。这个理解不算错，但漏掉了视图在基础篇体系里的真正定位——视图是外模式的实现手段，它承担的是“让不同用户看到不同数据”和“屏蔽底层结构变化”这两个职责。
从独立性的角度看，你把一张表拆成两张，只要原来的视图定义改一下（改成 join 两张新表），所有查这个视图的应用都不用动。这就是逻辑独立性在 SQL 层面的落地。从安全的角度看，你可以只把某些行、某些列做成视图授权给特定用户，底层表的其余部分完全不可见。这两点比“简化查询”重要得多。
视图还有一个实操上必须知道的分界：简单视图和复杂视图的可更新性不一样。如果一个视图是单表、没有聚合、没有 DISTINCT、没有子查询，它通常是可更新的，你对视图做 INSERT/UPDATE 会落到基表上；一旦涉及多表连接或聚合，更新行为就变得不确定，很多数据库直接禁止。这个规则我在笔记里写得很明确，因为实际项目里有人真的对着一个聚合视图去 UPDATE，报错之后一脸茫然。
3.4 索引不是“建了就快”
这是基础篇里和后面进阶篇衔接最紧的一处。索引本质上是内模式层面的一种额外存储结构，它不改变逻辑结构，只改变查找路径。理解了这一点，你就明白为什么索引属于物理独立性的范畴。
但“建索引就快”这个直觉有大量反例。第一，索引本身要占空间，要维护，每次插入更新删除都要同步更新索引，写的开销会上升。第二，如果查询的区分度很低（比如性别这种只有两三个值的列），走索引扫一大半数据，还不如直接全表扫。第三，如果查询条件里对索引列做了函数运算或类型转换，索引可能完全用不上。这三条我在笔记里都会写成“索引失效的典型场景”，实际排查时特别有用。
4. 规范化理论：判定范式必须按流水线走
规范化是基础篇公认的分水岭，很多人从这里开始掉队。我复盘过原因：教材讲函数依赖和公理系统讲得很数学，但做题时用不上，导致“看懂了但不会做”。我的建议是把它当成一条判定流水线来学，每一步都有明确的输入输出，不要靠直觉。
4.1 函数依赖的三个公理够用，别陷进推导里
Armstrong 公理只有三条：自反律（如果 Y 是 X 的子集，那么 X→Y）、增广律（如果 X→Y，那么 XZ→YZ）、传递律（如果 X→Y 且 Y→Z，那么 X→Z）。这三条是完备的，意思是所有能推出来的函数依赖都能由它们推出来。但实际做题时，你几乎用不到“完备性”这个性质，因为题目给的依赖集通常很小，直接算闭包就够了。
我在笔记里会补两条由公理导出的常用规则：合并规则（X→Y 且 X→Z，则 X→YZ）和分解规则（X→YZ，则 X→Y 且 X→Z）。这两条在化简依赖集时好用。但要注意，分解规则反过来不成立——X→Y 和 X→Z 能合并成 X→YZ，但 YZ→X 不能拆成 Y→X 和 Z→X。这个方向性错误是很多人算闭包时出错的原因。
至于最小依赖集（也叫最小覆盖），它的三步法值得背：右边单属性化、去掉左边多余属性、去掉多余依赖。这三步的顺序不能乱，因为第一步把右边拆成单个属性之后，第二步判断左边属性是否冗余才有意义。我见过有人先删冗余依赖再拆右边，结果删多删少都有。
4.2 范式判定的正确顺序是从 1NF 往上推
很多人拿到题直接判 3NF，结果漏判。正确的流程图是：先看 1NF（属性是否原子，有没有嵌套表），再看 2NF（有没有非主属性对候选码的部分依赖），再看 3NF（有没有非主属性对候选码的传递依赖），最后看 BCNF（有没有主属性对候选码的部分或传递依赖）。这个顺序不能跳，因为 2NF 是 3NF 的前提。
判 2NF 的关键是“部分依赖”，它只可能出现在候选码由多个属性组成的情况下。如果候选码是单属性，那么非主属性对它要么完全依赖要么不依赖，不可能部分依赖，所以直接满足 2NF。这个结论能省掉大量推导。
判 3NF 的关键是“传递依赖”，即 X→Y、Y→Z，且 Y 不是候选码、Z 不是主属性。经典例子：R(A, B, C)，F = {AB→C, C→B}。候选码是 AB 和 AC（因为 C→B，所以 AC 能推出 ABC），主属性是 A、B、C 全部，非主属性为空，所以它满足 3NF。但 C→B 这个依赖里，C 不是超码，所以不满足 BCNF。这个例子必须记在笔记本上，因为它是“3NF 但不 BCNF”的标准反例，理解它就理解了两者的区别。
我把这个对照写成了表：
| 范式 | 消除什么 | 判定要点 |
|---|---|---|
| 1NF | 属性不可再分 | 每个字段都是原子值 |
| 2NF | 非主属性对码的部分依赖 | 只在候选码为组合属性时才可能违反 |
| 3NF | 非主属性对码的传递依赖 | 每个非平凡依赖的左边是超码，或右边是主属性 |
| BCNF | 主属性对码的部分和传递依赖 | 每个非平凡依赖的左边都必须是超码 |
4.3 模式分解：无损连接和保持依赖是两件事
分解是规范化的落地动作，但分解有两个必须同时考虑的指标：无损连接性和保持函数依赖。这两个指标经常不能同时满足，实际工程里必须做取舍。
先说不损连接的判定。对二分解 ρ = {R1, R2}，如果 R1 ∩ R2 → (R1 − R2) 或者 R1 ∩ R2 → (R2 − R1) 成立，那么分解是无损的。举个反例：R(A, B, C)，F = {A→B, C→B}，分解成 R1(A, B) 和 R2(B, C)。R1 ∩ R2 = B，B 能推出 A 吗？不能；能推出 C 吗？不能。所以这个分解是有损的，你把它 join 回去会多出不存在的数据。
换个分解方式：R1(A, B) 和 R2(A, C)。R1 ∩ R2 = A，A→B 成立（B 就是 R1 − R2），所以无损。但 C→B 这个依赖在两个子模式里都推不出来，所以不保持依赖。这就出现了典型的冲突：无损但不保持依赖。在实际系统里，如果不保持依赖，意味着某些约束无法在单个表上通过主键或唯一约束来保证，只能在应用层检查，这是有代价的。
我的笔记里会写一句总结性的话：规范化到 3NF 通常可以同时做到无损和保持依赖，但到 BCNF 就可能牺牲保持依赖。这是 3NF 和 BCNF 之间的一个经典权衡，也是为什么很多实际系统停在 3NF 的原因。
4.4 别把范式当教条，反规范化是真实存在的
这一条是工作之后才补上的认知。教材把规范化讲得很彻底，但实际做项目时你会发现，过度规范化会带来大量 join，查询性能下降。所以在数据仓库或者读多写少的场景里，反规范化是常规操作——故意保留冗余字段，减少连接次数。
但反规范化的前提是你清楚自己在放弃什么。冗余字段会带来更新异常：同一份数据存在多处，改一处忘一处就不一致了。所以要么用触发器维护，要么在应用层用事务保证一致性，要么接受最终一致。我在笔记里给这条留了一行：反规范化不是“不规范”，是“用可控的冗余换性能”，前提是能说清楚一致性由谁保证。
5. 事务与并发控制：基础篇里最容易“背了不会用”的一章
事务这一章的内容看起来是纯记忆——ACID 四个字母、三种并发异常、四个隔离级别、三级封锁协议、两段锁协议。但如果你只是背，一遇到“这个场景该用哪个隔离级别”就答不上来。我的经验是按照“异常→隔离级别→封锁协议→日志恢复”这条线去理解，每一层都在解决上一层的问题。
5.1 ACID 各自对应数据库里的哪个机制
原子性讲的是“要么全做要么全不做”，对应的实现是日志和回滚。一致性讲的是“从一个一致状态到另一个一致状态”，它其实是目的不是手段，靠的是约束加上事务。隔离性讲的是“并发事务之间互不干扰”，对应的是锁或者多版本并发控制。持久性讲的是“提交了就一定在”，对应的是日志落盘和检查点。
这么一对，ACID 就不是四个抽象名词了，而是四组具体的实现机制。我在笔记里会把这张对应关系写下来，因为它解释了为什么一章里要同时讲并发控制（服务隔离性）和恢复技术（服务原子性和持久性）——它们是同一个目标的两个侧面。
5.2 三种并发异常，要从“为什么会发生”去记
丢失修改、不可重复读、读脏数据，这三个异常很多人是死记名字，其实只要想清楚“两个事务在什么时序下交叉执行”就自然能推出来。
丢失修改：两个事务同时读同一行，各自基于读到的值做修改，后写的覆盖了先写的。关键在于“读-改-写”这个序列被交叉了。不可重复读：事务 T1 第一次读某行，T2 修改并提交了这行，T1 再读发现变了。关键在于“读-别人改-再读”被插入了一次修改。读脏数据：T1 修改了某行还没提交，T2 读到了这个未提交的值，之后 T1 回滚，T2 读到的是从来没存在过的数据。
这三者的严格程度是递进的：读脏数据最严重（读到不存在的数据），不可重复读次之（数据存在但前后不一致），丢失修改是另一类（修改被覆盖）。理解了这个递进关系，你就能理解隔离级别为什么这样设计。
5.3 隔离级别的选择是业务权衡，不是越高越好
读未提交、读已提交、可重复读、串行化，这四个级别分别能防止哪些异常，这张表必须记牢。但更重要的是知道为什么大多数系统默认不用最高级别——因为串行化的并发性能太差，大量事务排队等待，吞吐量急剧下降。
实际选型时的判断逻辑是：先看这个业务能不能容忍不可重复读。比如统计报表跑的过程中，如果同一张表被别的业务改了，两次查出来的数不一样，这通常是可以接受的，那就用读已提交。但如果是一个涉及金额的校验流程，同一个事务里连续读两次账户余额必须一致，那就要可重复读。这一层判断，教材不会教你，得靠实际场景积累。
5.4 两段锁协议的正确理解方式
两段锁协议（2PL）说的是：事务分为扩展阶段和收缩阶段，扩展阶段可以加锁不能释放，收缩阶段可以释放不能加锁。它保证的是冲突可串行化，注意不是“不会死锁”。很多人把这两个概念混在一起，以为遵守 2PL 就没有死锁，其实 2PL 只保证结果等价于某个串行执行，死锁是完全可能的。
死锁的处理有预防和诊断两条路。预防有“一次封锁法”（把所有要用的数据一次性全锁住）和“顺序封锁法”（所有事务按固定顺序加锁），代价都是并发度下降。诊断有“超时法”（等太久就认为死锁）和“等待图法”（画图找环）。实际系统里超时法更常见，因为它实现简单，代价是可能误杀。
我在笔记里会把这一条加粗：2PL 保证的是可串行化，不是无死锁。这个区分在面试和实际排查中都很有用，因为有人看到死锁就以为隔离级别设错了，其实只是加锁顺序不一致。
5.5 日志和恢复：三个故障类型对应三套动作
恢复技术这一节，我建议按故障类型来组织，而不是按概念来组织。事务内部的故障（比如除零、违反约束），做 UNDO，把这个事务已经做的操作反向执行一遍。系统故障（比如断电、进程崩溃），做 UNDO 加 REDO，把没提交的事务回滚，把已提交但可能没写进磁盘的事务重做。介质故障（磁盘坏了），先重装最近的数据库副本，再用日志重做。
这里有个关键原则必须记牢：先写日志，后写数据库，也就是 WAL。原因是如果先写数据库再写日志，中间崩溃了，你不知道这个修改该不该保留。先写日志的话，即使数据库没来得及写，也能靠日志重做出来。这个顺序是不能反的，反过来整个恢复机制就失效了。
检查点的作用也值得记一笔。如果没有检查点，系统恢复时要把整个日志从头扫一遍，时间不可控。检查点相当于一个“截止线”，它保证检查点之前已经提交的事务一定已经写进了数据库，恢复的时候只需要从检查点往后扫。这个设计思路和很多系统的快照机制是一样的。
6. 把笔记变成能跑的东西：我的落地做法
概念捋清楚之后，还有一个问题：怎么保证这些笔记不是“抄完就忘”。我用过一个很土但有效的办法——每学完一章，就在本地建一个能跑的小库，把这一章的概念全部变成可以执行的语句。
具体做法是：学完关系模型，建三张有外键关联的表，故意插入违反约束的数据看报错；学完 SQL，把同一道查询用不同写法实现，对比执行结果差异；学完范式，拿一张自己设计得很烂的表，一步步拆到 3NF，然后把拆分前后分别 join 回去，验证数据有没有丢；学完事务，开两个会话手动模拟并发，观察不同隔离级别下的现象差异。
这个方法最大的价值在于，报错信息会逼你去理解概念。你插一条外码不存在的数据，数据库告诉你违反参照完整性，你对这条约束的记忆就固定了；你在 WHERE 里写等号比较空值，一行查不出来，你对三值逻辑的印象就深刻了。这比看十遍定义都管用。
关于笔记的复盘节奏，我的习惯是每学完一个大章，用一页纸把这章的概念画成一张关系图，然后合上书，试着用口述的方式讲一遍。讲不下去的地方就是没真懂的地方，回头补。这个自测方式比刷题准，因为题目有提示，口述没有。
最后分享一个我踩过的坑：我一开始喜欢把笔记做得很漂亮，各种颜色标注、各种排版，结果花在排版上的时间比理解还多。后来改成“能看懂就行”，把省下来的时间全部用在动手验证上，效果反而好得多。笔记的作用是让你以后能快速捡起来，不是让你当下有成就感。
