关系代数：从数据库原理到SQL优化与查询设计的底层逻辑

讲数据库绕不过关系代数，这几乎是每个信息科学相关专业学生的必经关卡。但说实话，很多人在学这门课的时候会把它当成纯粹的数学推导，学完之后除了应付考试，压根没觉得它跟日常写SQL有什么关系。我当年也是这样，直到自己在一次课程设计里被一个多表查询卡了整整两天，回头翻教材才发现，关系代数不是孤立的学术概念，它是SQL的底层逻辑，是数据库优化器判断一条查询该怎么执行的理论依据。

这篇文章我就围绕数据库、关系代数这两个核心话题，把这块内容系统梳理一遍。不管你是正在学数据库基础的学生，还是在做数据库课程设计时被复杂查询折磨的开发者，又或者是想搞懂MySQL、Oracle、达梦这类关系型数据库内部工作机制的从业者，这篇内容都能帮你把“关系代数到底有什么用”这件事彻底想明白。

1. 关系代数不是一门学科，而是SQL的幕后推手

1.1 信息科学工程里，为什么关系型数据库能统治主流市场

先聊一个看起来有点大、但必须得聊清楚的问题：信息科学领域里，数据库发展了几十年，中间出现过网状模型、层次模型，也出现过各种NoSQL和分布式存储方案，但直到今天，大部分企业的核心业务系统依然跑在关系型数据库上，比如MySQL、Oracle、PostgreSQL、SQL Server、达梦、人大金仓这些。

原因当然有很多，比如事务的一致性保障、成熟的生态工具链、运维体系完善等等。但在理论层面，最根本的原因就是关系模型站得住脚。关系模型由E.F.Codd在1970年提出，它的核心思想是把数据组织成一张张二维表，表与表之间通过公共属性建立联系。而关系代数，就是在这个模型之上定义的一套形式化查询语言。

这套查询机制的价值在哪儿？用一个不太严谨但很直观的类比：如果你把数据库看成一座大型仓库，表是货架，数据是货物，关系代数就是一套标准的“拣货指令系统”。你不需要告诉仓库管理员具体走哪条路线、先开哪扇门，只需要告诉他“从3号货架拿A类货物，从5号货架拿B类货物，然后把两边匹配起来”。至于仓库内部怎么规划路线最高效，是仓库系统自己决定的事。

数据库里干这件事的系统，就叫查询优化器。它读取你写的SQL，先把SQL翻译成关系代数表达式，然后利用关系代数的等价变换规则，找出执行代价最小的方案。所以如果你不理解关系代数，你看到的只是“SQL跑得慢”，但始终不明白为什么换个写法就快了。

1.2 为什么说关系代数既是SQL的祖先，又是SQL的优化器

严格来说，SQL语言在诞生之初就参考了关系代数和关系演算的设计思想。SQL里的SELECT、FROM、WHERE、JOIN这些关键字，你几乎都能在关系代数中找到对应的运算符。关系代数中的选择（Selection）对应WHERE子句，投影（Projection）对应SELECT后面的字段列表，连接（Join）对应各种JOIN。

但SQL和关系代数有一个重大差别：SQL是面向用户的、接近自然语言风格的声明式语言，你告诉数据库“我想要什么”就够了；而关系代数更像是一种中间的、形式化的语言，它明确地表达“怎么计算这些数据”。数据库引擎会把你的SQL先解析成抽象语法树，再转换成关系代数表达式，最后通过优化器对表达式进行等价变形，生成执行计划。

所以你可以这么理解：关系代数是SQL的“幕后语言”。你写SQL时感觉是在直接操作表，实际上数据库内部先把它翻译成了关系代数的运算序列。学习关系代数，不是为了自己手动去算那些运算，而是为了理解数据库到底怎么对待你的查询。

这个认知一旦建立，你再看那些“为什么这个SQL走了全表扫描”“为什么加了索引也没用”“为什么这俩查询结果一样但性能差十倍”的问题，就有了全新的视角。

2. 关系数据模型的基本单位：从一张张表说起

2.1 关系、元组、属性、域——四个必须一次搞清的概念

关系代数是建立在关系数据模型之上的。所以在接触运算符之前，先把几个基础概念弄扎实，否则后面全是糊涂账。

• 关系（Relation）：就是一张二维表，有表名、有列、有行。关系名对应表名。
• 元组（Tuple）：表中的一行数据。一个关系是所有元组的集合。
• 属性（Attribute）：表中的一列。属性有名字，也有取值范围。
• 域（Domain）：某个属性的取值范围。比如“年龄”属性的域是0到150的整数，“性别”属性的域可以是{男，女}的枚举值。

这里有一个关键点：关系是元组的集合。注意“集合”这两个字。在数学里，集合的元素是唯一的，集合中没有重复元素，元素之间没有顺序。对应到关系模型上，就是：

• 表中不允许出现完全相同的两行（元组的唯一性）
• 表中行的顺序无关紧要（集合的无序性）

这个观念在后续学关系代数时会反复用到。比如后面讲投影运算时，如果结果集合里出现了重复行，按照严格的关系代数定义，重复行会被去掉。但在实际SQL中，默认会保留重复行，除非你显式加DISTINCT。这就是理论和工程实现之间一个很典型的差异。

2.2 候选键、主键、外键：关系模型里的“身份证”

关系代数做连接运算时，靠的就是不同关系之间的“公共属性”，而这些公共属性通常与键的概念紧密相关。

• 候选键（Candidate Key）：能够唯一标识一个元组的最小属性集合。比如学生表里，学号可以唯一确定一名学生，那么学号就是一个候选键。如果学号和姓名组合在一起也能唯一确定学生，但姓名不是必需的，那么{学号，姓名}就不是最小集合，不能作为候选键。
• 主键（Primary Key）：从多个候选键里挑一个作为主要标识。主键的值不能为空，也不能重复。
• 外键（Foreign Key）：一个表中的某个属性或属性组合，引用另一张表的主键。外键表达的是表与表之间的关联关系。比如选课表里的学号，引用学生表里的学号，那么选课表里的学号就是外键。

为什么在关系代数里要先强调键？因为以后做自然连接时，系统是拿两个关系中同名的属性做匹配的。如果同名属性本身不是键，很可能匹配出来的结果集会有数据膨胀，也就是我们常说的笛卡尔积效应，这个后面细讲。

2.3 为什么说“集合”的视角比“表”的视角更接近数据库底层的真相

日常工作里，大多数人习惯把表当成一个Excel表格：有行有列，可以随意排序，每一行有行号。但关系代数把表看成集合，这个视角转换非常关键。

如果把表看成“有序表格”，你就会默认每行有位置概念，操作时也会考虑“插入到第几行”“交换两行位置”。但关系模型明确告诉你：行的物理顺序没有任何语义。数据库存储引擎底层可能用堆表、索引组织表、列存等各种方式存储数据，物理顺序完全由存储引擎决定。你今天查询出来的顺序，和明天、换了一个执行计划之后的顺序，都可能不一样。

所以关系代数里完全不涉及“排序”运算。排序是SQL中一个非关系的扩展功能，主要用于展示层。理解这一点，能帮你避免一个新手常见错误：以为SELECT * FROM 表返回的行顺序是有保证的，然后在应用层依赖这个顺序做逻辑判断。实际上，要保证顺序就应该使用ORDER BY，而ORDER BY是语义上的操作，不是底层存储的自然属性。

3. 八个关系运算逐个拆解：把数据库操作当成集合计算

关系代数提供了若干运算符，概括起来可以分为传统集合运算和专门的关系运算两大类。传统集合运算包括并、差、交、笛卡尔积；专门的关系运算包括选择、投影、连接、除。下面逐个把它们讲透，每一个都会对应回SQL怎么做。

3.1 选择（σ）：按行过滤，对应SQL的WHERE

选择运算是从一个关系中筛选出满足给定条件的元组。记作 σ_条件(关系名)。

比如 σ_成绩>90(选课表)，意思是把选课表中成绩大于90的所有行挑出来。

这个运算有几个特点需要记住：

• 结果关系与原始关系有相同的属性结构，只是行的数量可能减少了。
• 条件的写法沿用逻辑表达式，支持>、<、=、>=、<=、<>、AND、OR、NOT这些逻辑组合。

选择运算在SQL中对应的就是WHERE子句。比如：

sql复制SELECT * FROM 选课表 WHERE 成绩 > 90;

你也许会想：这不就是加个过滤条件吗，有什么可学的？但关系代数的价值在于，它是形式化的。你可以对条件做逻辑推演，比如 σ_条件A AND 条件B(R)，等价于 σ_条件A(σ_条件B(R))。看起来没什么，但这种等价变换正是查询优化器做谓词下推的依据。把过滤条件提前到连接之前执行，能大幅减少参与连接的数据量，这是SQL优化的核心手段之一。

3.2 投影（π）：按列裁剪，对应SQL的SELECT列表

投影运算是从一个关系中选取指定的几个属性列，组成一个新关系。记作 π_属性1,属性2(关系名)。

比如 π_学号,课程号(选课表)，就是只看学号和课程号两列。

投影运算有两个容易忽略的细节：

• 投影会返回所有满足条件的元组，但结果关系中如果出现了重复元组，在纯关系代数中是要去掉的。因为关系是集合，不允许重复。
• SQL中默认不去重，但你用SELECT DISTINCT时，就相当于做了真正的投影运算。

例如：

sql复制SELECT DISTINCT 院系 FROM 学生表;

这句SQL在关系代数里就是 π_院系(学生表)。

选择关注的是一行行看，投影关注的是一列列看。二者组合起来，就是SQL里最基础的“从哪张表选哪些列，过滤哪些行”的操作。

3.3 并、差、交：集合运算的老三样

并（Union）、差（Difference）、交（Intersection）是传统集合运算在关系模型中的应用。它们要求参与运算的两个关系必须是并兼容的，意思是：

• 属性个数相同
• 对应属性的域相同（或者说类型兼容）

并运算 R∪S：取R和S中所有元组，去掉重复的。对应SQL的UNION，注意UNION默认去重，UNION ALL不去重。

差运算 R−S：取属于R但不属于S的元组。SQL中可以用EXCEPT（部分数据库）或者NOT IN、NOT EXISTS实现。

交运算 R∩S：取同时属于R和S的元组。SQL中可以用INTERSECT，也可以改写成IN加子查询实现。

这三个运算在实际课设中非常常见。比如“查询选了课程1但没选课程2的学生”，这种需求用差运算就非常自然：

code复制π_学号(σ_课程号='c1'(选课表)) − π_学号(σ_课程号='c2'(选课表))

如果完全靠SQL硬写，会有各种写法，但关系代数的思路最接近问题的本质。

3.4 笛卡尔积：麻烦又强大的底层运算

笛卡尔积是理解连接操作的关键。两个关系的笛卡尔积，记作 R×S，就是把R的每个元组与S的每个元组配对一次。如果R有m个元组，S有n个元组，结果就有m×n个元组。

为什么说它麻烦？因为实际业务数据量一大，笛卡尔积的结果会爆炸式膨胀。比如学生表一万行，课程表一千行，笛卡尔积就是一千万行，这还只是两张小表。

但为什么又说它强大？因为连接运算在数学定义上就是从笛卡尔积中筛选出符合条件的元组。也就是说：

• 等值连接 = 先做笛卡尔积，再按某两个属性值相等来筛选
• θ连接 = 先做笛卡尔积，再按某个比较条件来筛选

SQL里的CROSS JOIN就是笛卡尔积，JOIN ... ON 条件在逻辑上就等价于先笛卡尔积再过滤。

这里要反复强调一点：明白这个逻辑以后，千万不要在SQL里写出不带条件的JOIN。一旦忘了加ON条件，数据库就会真的做笛卡尔积，数据量一大，性能直接崩。

3.5 连接家族：θ连接、等值连接、自然连接

连接（Join）是关系代数里最常用也最容易搞混的一组运算。

θ连接（Theta Join）：从R和S的笛卡尔积中，选出满足某个比较条件θ的元组。θ可以是大于、小于、不等于等任意比较运算符。记作 R ⋈_θ S。

等值连接（Equi Join）：θ条件里只使用“=”的连接。比如 R ⋈_{R.A = S.B} S。结果里会保留两个同名的属性列（或者表达式涉及的所有列）。

自然连接（Natural Join）：这是一种特殊的等值连接。它要求两个关系按照所有同名的属性做等值匹配，并且在结果中把重复的同名属性列合并为一列。

举一个具体例子。学生表（学号，姓名，院系），选课表（学号，课程号，成绩）。两表有同名列“学号”。

• 等值连接 学生表 ⋈_{学生表.学号=选课表.学号} 选课表，结果列是（学生表.学号，姓名，院系，选课表.学号，课程号，成绩），学号出现两次。
• 自然连接 学生表 ⋈ 选课表，结果列是（学号，姓名，院系，课程号，成绩），学号只出现一次。

SQL中自然连接可以直接写NATURAL JOIN，但实际开发中我建议少用。原因就是它的匹配规则是“所有同名属性都做等值匹配”，一旦表结构变动，比如两张表里新增了一个意义不同的同名列，自然连接的语义就会悄悄改变，查出来的结果很可能不是你想要的。更稳妥的做法是显式JOIN ... ON 明确指定连接列。

连接之后如果发现结果行数异常增加，多半是连接列存在重复值。比如选课表里同一个学号有多条选课记录，和学生表做连接时，学生表里的一个学号就会对应选课表里的多行，结果行数变多，这是正常现象。很多刚学数据库的人会在这一步犯迷糊，认为是数据错了，其实不是。

3.6 除运算：解决“至少选了所有课程的学生”这类难题

除运算（Division）是关系代数里最抽象的一个运算。它解决的问题是“对于R中的每个值，都对应S中的所有值”。典型需求：“查询选修了全部课程的学生学号”“查询至少选修了学号S1所选课程的所有学生学号”。

这里要注意，除运算的形式定义是：R ÷ S。结果关系的属性是R中不出现在S中的那些属性，并且结果中的每个元组与S中所有元组组合后，都能在R中找到对应元组。

用集合的观点看，设学生选课关系为SC(学号，课程号)，课程关系为C(课程号)。要查询选修了所有课程的学生，就是 SC ÷ π_课程号(C)。

如果不用除法，用SQL实现这类需求基本要走两层NOT EXISTS或者用GROUP BY加HAVING COUNT(*)来做。

以“查询选修了全部课程的学生学号”为例，SQL可以这样写：

sql复制SELECT 学号
FROM 选课表
GROUP BY 学号
HAVING COUNT(DISTINCT 课程号) = (SELECT COUNT(*) FROM 课程表);

但这个写法有个前提：选课表里不能出现课程表中不存在的课程号。如果数据不干净，统计口径就会有偏差。用关系代数的除运算来理解这个查询，逻辑会更清晰——你要找的其实是“选课集合覆盖了全部课程集合”的那些学号。

除法在数据库课程设计和面试里都是高频考点，因为它考察的是你能不能把一个业务描述翻译成形式化的逻辑表达式，而不是机械地背SQL语法。

4. 从关系代数到SQL的翻译路径：把课堂知识变成拿得出手的查询

4.1 关系代数表达式翻译成SQL的基本套路

学习关系代数的最终目的，不是让你以后写SQL时先在纸上画出表达式，而是让你心里有这张“对照表”。这里我把最常用的对应关系整理一下：

这张表建议收藏，做数据库课程设计时几乎每一条都能用上。

4.2 从需求到关系表达式的完整推演：以教务系统为例

直接给一个贴近实际的案例。假设有三个关系：

• 学生（学号，姓名，院系）
• 课程（课程号，课程名，学分）
• 选课（学号，课程号，成绩）

需求一：查询计算机学院学生的学号和姓名。

解析步骤：先对学生表做选择，条件是院系='计算机学院'；再做投影，取学号和姓名。

关系表达式：π_学号,姓名( σ_院系='计算机学院'(学生) )

SQL：

sql复制SELECT 学号, 姓名 FROM 学生 WHERE 院系 = '计算机学院';

需求二：查询选修了“数据库基础”课程的学生姓名。

这个需求跨了三张表，典型的连接加选择再加投影。

先用课程表选出课程名为“数据库基础”的课程号，然后和选课表做自然连接，再和学生表做属性匹配，最后投影姓名。

关系表达式：π_姓名( 学生 ⋈ (选课 ⋈ (σ_课程名='数据库基础'(课程))) )

SQL：

sql复制SELECT DISTINCT s.姓名
FROM 学生 s
JOIN 选课 sc ON s.学号 = sc.学号
JOIN 课程 c ON sc.课程号 = c.课程号
WHERE c.课程名 = '数据库基础';

需求三：查询没选任何课程的学生姓名。

这个需求就是差运算的典型应用。查出所有学生的学号，减去选课表里出现过的学号，再和学生表连接取姓名。

关系表达式：π_姓名( 学生 ⋈ (π_学号(学生) − π_学号(选课)) )

SQL：

sql复制SELECT 姓名 FROM 学生
WHERE 学号 NOT IN (SELECT DISTINCT 学号 FROM 选课);

这三个需求从易到难，基本覆盖了选择、投影、连接、差运算的常规组合方式。做课设的时候遇到任何查询需求，建议先在纸上把关系的逻辑确定下来，再翻译成SQL，这样能少走很多弯路。

4.3 关系代数表达式树：把查询计划画出来

在实操层面有一个非常实用的工具叫查询表达式树。它就是把关系代数表达式按运算顺序展开成一棵树，叶子节点是基础表，内部节点是运算符，根节点是最终结果。

为什么要画这棵树？因为它能帮你看清楚一条SQL的执行顺序。

以需求二为例，它的表达式树大概是：

• 叶子：课程、选课、学生
• 第一层：对课程做选择（课程名='数据库基础'）
• 第二层：选择结果与选课做连接
• 第三层：连接结果与学生做连接
• 根：对结果做投影（姓名）

画完这棵树以后，你会发现一个优化的关键点：如果先把课程表过滤到只剩“数据库基础”这一门课，再去和选课表连接，参与连接的数据量就非常小。这个顺序就是优化器经常做的“先过滤，再连接”。你在SQL里手动用子查询先去查课程号，本质上也是在人工引导优化器走这条路径。

这个“先过滤再连接”的思路，放在任何关系型数据库里都适用，不管你在MySQL、PostgreSQL还是达梦数据库上，底层优化器都有类似的规则，但人工理解这个逻辑对排查慢SQL极有帮助。

5. 实际应用与易错点排查：从MySQL到达梦都通用的基本功

5.1 数据库优化器是怎么利用关系代数规则的

关系代数之所以有用，不只是因为它能表达查询语义，还因为它有一套等价变换规则。查询优化器的很多核心逻辑，都是建立在这些规则之上的。

最常用的几条等价变换规则包括：

• 连接和选择的交换律：σ_条件(R ⋈ S) 可以变换为 σ_条件(R) ⋈ S，在某些条件下能变换成 (σ_条件1(R)) ⋈ (σ_条件2(S))，也就是把过滤下推。
• 投影的串接：π_列1(π_列2(R)) 等价于 π_列1(R)，前提是列1是列2的子集。
• 笛卡尔积与连接的结合律：R ⋈ S ⋈ T 可以先两两连接，顺序可以调整。

这些规则看起来是数学推导，实际上每天都在数据库内核里运行。比如你的SQL里写了WHERE 院系='计算机学院' AND 学号 IN (SELECT 学号 FROM 选课)，优化器可能会把院系的过滤条件下推到子查询之前或之后执行，从而减少扫描的数据量。

理解这个机制后，你在调优慢SQL时会有更明确的方向：考虑参与运算的数据量，考虑过滤条件下推是否生效，考虑连接顺序是否合理，而不是盲目加索引。

5.2 关系代数中的空值问题：一个很多教材一笔带过的陷阱

关系代数的传统定义建立在集合论之上，默认每个元组都是完整且确定的。但现实数据库里到处是NULL，这就带来了一些经典问题。

关系代数里的比较运算遇到NULL时，结果既不是TRUE也不是FALSE，而是UNKNOWN。于是σ_成绩>90(选课表)这个表达式，遇到成绩为NULL的行时，该行不会被选中。

和你的直觉判断是否一致？很多人一开始以为NULL会被当作0处理，或者会被当作“不满足大于90”而排除。结果确实是被排除了，但原因不是“不满足条件”，而是“条件的真假未知，所以不能保留”。这区别体现在哪？体现在反向查询上。

比如你写了这样一个SQL：

sql复制SELECT * FROM 选课 WHERE 成绩 <= 90;

你会不会以为这个SQL能查出“所有成绩不大于90的记录”，包括那些没有成绩的记录？实际上不会。因为NULL既不满足“>90”，也不满足“<=90”，它在两种比较中都产生UNKNOWN，都会被过滤掉。如果要查出成绩为空的行，必须显式写WHERE 成绩 IS NULL。

在关系代数的视角下，就是：选择运算是按照“条件取值是否为TRUE”来决定是否保留元组的，UNKNOWN一律不保留。这一点在做数据清洗、报表统计时非常容易踩坑。

5.3 关系代数去重逻辑和SQL默认行为不一致的实战影响

前面提到，关系是集合，所以关系代数里所有运算结果天然没有重复行。但SQL是基于多重集的，默认情况下SELECT不会去重。这就导致一个非常常见的实际差异：如果你按照关系代数的思路去理解SQL查询结果集的大小，行数可能对不上。

来看一个例子。有一个选课表（学号，课程号），数据如下：

查询“选过课的学生学号”，用SQL写：

sql复制SELECT 学号 FROM 选课;

结果会返回三行，其中学号1出现两次。但如果用关系代数 π_学号(选课)，结果应该只有两行{1, 2}。

这种差异在实际开发里很容易造成BUG。比如你统计“有多少人选过课”，如果直接对上面那条SQL的结果做count()，会得到3，但正确答案应该是2。正确写法是：

sql复制SELECT COUNT(DISTINCT 学号) FROM 选课;

所以看到“为什么SELECT查询结果和预期行数不一样”的怪问题时，先检查一下有没有漏掉DISTINCT。关系代数能帮你建立这种敏感度。

5.4 从关系代数看慢查询的排查思路

你在MySQL、Oracle、达梦这类数据库上做慢查询排查时，最常见的场景就是多表JOIN之后性能急剧下降。用关系代数的思路来拆解，问题往往出在参与连接的数据量没有提前压缩。

举个例子，一个查询需要先按学生所在院系过滤，再连接选课表。如果写成：

sql复制SELECT s.姓名, sc.课程号
FROM 学生 s
JOIN 选课 sc ON s.学号 = sc.学号
WHERE s.院系 = '计算机学院';

优化器如果足够聪明，会把WHERE s.院系='计算机学院'这个条件下推到学生表扫描阶段，先过滤再连接。但如果优化器因为统计信息不准或者其他原因选择了先连接再过滤，那么参与连接的数据量就会非常大，查询自然就慢。

手动改写的方式可以是：

sql复制SELECT t.姓名, sc.课程号
FROM (SELECT 学号, 姓名 FROM 学生 WHERE 院系 = '计算机学院') t
JOIN 选课 sc ON t.学号 = sc.学号;

这本质上就是你在手动指导优化器执行关系代数里的等价变换规则。在达梦数据库、人大金仓这些国产数据库上，优化器能力参差不齐，遇到慢查询时手动做这样的改写非常常见。

再看另一个典型慢查询：三张表连接，顺序不同，性能差异巨大。关系代数里连接满足结合律，A⋈B⋈C可以先连A和B，也可以先连B和C。实际执行时，选择哪个连接顺序，取决于中间结果的大小。如果A和B连接后产生100万行，而B和C连接后只产生10行，明显应该先连B和C。优化器做这个决策时依赖统计信息，但统计信息有时不准。遇到这种情况，你需要基于自己对数据分布的理解，在SQL里调整连接顺序，或者用子查询强制先做某个连接。

这些内容，就是关系代数在真实数据库工程里最直接的应用。

5.5 为什么说关系代数能帮你迁移到国产数据库也不慌

写到这里想延伸一个最近几年很普遍的场景：越来越多团队从Oracle迁移到达梦、人大金仓这类国产数据库，或者在做数据库课程设计时直接选型达梦。然后你会发现，虽然是不同产品，但SELECT、WHERE、JOIN这些语法基本通用，因为它们共享同一个理论根基，也就是关系代数和关系模型。

遇到过一个问题，某国产数据库产品对NATURAL JOIN的支持和MySQL表现不一致，导致SQL语义发生变化。这时候如果你懂关系代数，就知道自然连接的本质是“按公共属性集合做等值连接并且合并同名列”，你就可以自己改写成显式的JOIN ... ON，彻底绕开产品差异带来的不可控因素。

反过来，如果你只记某一种数据库的方言语法，不理解底层的运算逻辑，换一个数据库就像重新学一遍。知识迁移能力这东西，不是靠多背几种SQL方言获得的，靠的是把关系代数这套稳定的底层逻辑吃透。

最后再分享一点我的个人体会

我见过太多人在学数据库时一上来就刷SQL题，到最后能写不少复杂查询，但是遇到两个问题就露馅：一个是查询结果不对时不知道该怎么调试，因为脑子里没有“逻辑运算顺序”的概念；另一个是同样的功能换一种写法性能差很多，却说不出为什么。这两个问题的根子，都在于缺少关系代数这个理论坐标系。

关系代数学起来确实有一点抽象，我建议你用最笨的方法去消化它：每学一个运算符，就找真实业务场景手写一个对应的关系表达式，再翻译成SQL对照结果。比如把自己熟悉的图书管理、超市收银、学生选课这三类场景各写一遍，基本上所有运算符都能覆盖到，比单纯看教材推导管用得多。等你哪天写SQL想到某个复杂查询时，脑子里第一反应不是“SELECT该怎么套”，而是这个问题要先过滤、映射还是先做差集，那时候你就真正过关了。