关系模型与关系代数
先抛一个我自己的真实经历：刚工作那年负责一个报表接口，SQL写得洋洋洒洒，三四十行嵌套子查询，当时觉得很“厉害”。第一次上线数据量小，跑得挺快；等用户数据翻了几倍之后，某个凌晨接口超时，DBA甩来一条慢查询日志，里面是我那段“炫技”SQL。他看完只说了一句：你能不能先想想，你真正要在表上执行什么关系运算？那次之后我才回头认真把关系代数补了课。
其实关系模型和关系代数，是所有数据库从业者绕不开的一层理论基础。虽然每天写SQL的人可能不会天天提“σ”“π”“⋈”这些符号，但查询优化器内部、索引选择策略、SQL改写规则，全部建立在这套数学体系之上。这篇文章我想以工程视角重新拆一遍关系模型和关系代数：不只讲定义，而是讲清楚它们到底解决了什么、怎么用、以及和SQL之间的映射关系。适合正在学数据库原理的人，也适合写过几年SQL但想弄清楚“为什么这么写是慢的、那么写是快的”的开发者和数据分析师。
1. 关系模型：它远比“一张表”更严格
很多人理解关系模型，就说“关系就是表”。这个说法对工程产品不算错，但放在理论层面，它会漏掉最重要的一层——关系的数学性质。我们之所以能在几十亿行数据上做复杂查询，恰恰是因为关系模型把数据定义成了一种结构严谨的数学对象。
1.1 为什么需要确定性的数据抽象
早期数据库应用，基本是“程序代码 + 文件系统”的拼凑。每个程序自己定义数据格式、自己管理文件读写、自己处理映射关系。当时有个很要命的问题：数据格式只要一变，所有读写它的程序都要跟着改。数据访问路径被锁死在程序里，数据和程序之间没有中间抽象层。
1970年，E.F. Codd在《A Relational Model of Data for Large Shared Data Banks》里提出了一个反直觉的思路：把数据暴露给用户的，不应该是指向物理存储位置的指针，也不应该是某种依赖具体实现的数据结构，而是一种统一、干净、有数学保障的对象——关系。关系模型的核心主张是：用户看到的、操作的都是关系，至于底层怎么存、怎么索引、怎么组织，对用户透明。
这套模型的价值在于，数据与程序之间终于隔开了一层。应用程序只需要面向表、行、列来写逻辑，物理存储怎么调整，甚至从一张表拆成两张表，只要外模式不变，程序就不需要动。用今天的眼光看，这就是逻辑数据独立性和物理数据独立性的起点。
关系模型由三部分构成：数据结构、完整性规则、操作语言。结构定义关系长什么样；完整性规则约束哪些数据是合法的；操作语言就是关系代数——一组封闭的运算，让用户能从已知关系出发，推导出目标关系。三者合一，才构成真正意义的数据库理论底座。
实际工程里，我们每天写的SQL只是这套理论的一个外层语法。优化器在执行之前，会先把SQL翻译成某种关系代数形式的执行计划，再基于这个计划做各种等价变换。所以弄懂关系代数，本质上是弄懂数据库优化器的“母语”。
1.2 从集合论看关系：域、元组、属性、键
关系的严格定义来自集合论：给定一组域 D1、D2、…、Dn，关系 R 是 D1×D2×…×Dn 的一个子集。说得白话一点：先规定每个列能取值的范围，再从这个范围的全组合中挑出一部分符合业务含义的元组，组成一张表。
落到工程上，几个概念对应如下：
- 域（domain）：属性的取值范围。比如“年龄”域是非负整数，“性别”域是{男, 女}；
- 元组（tuple）：表中的一行；
- 属性（attribute）：表中的一列；
- 关系模式（relation schema）：表名加属性名列表，对应建表语句里的表结构；
- 关系实例（relation instance）：某一时刻关系里的具体元组集合，对应表中的数据。
关系的集合性带来了三个十分严谨的推论：
第一，元组之间没有顺序。也就是说，关系不是“数组”，不是“列表”，而是一个集合。查询结果的顺序天然不确定，除非你显式ORDER BY。
第二，关系不允许出现完全重复的元组。集合里不存在两个一模一样的元素。这一点在严谨的数学模型里是铁律，工程上MySQL、PostgreSQL这类数据库默认允许重复行，因为为了性能牺牲了部分理论一致性。但一旦做DISTINCT，你其实是在向关系模型的集合语义“回归”。
第三，每个元组的每个属性值必须是原子的。这个约束比很多人想象的严格：属性值不能是集合，不能是嵌套结构，不能是数组。第一范式（1NF）要求的本质，就是让所有属性都落回标量值。为什么这么规定？因为一旦允许属性值内部再嵌套数据，查询语言就从一阶逻辑滑向了更复杂的非一阶逻辑，推导规则、等价变换、优化策略都会急剧复杂化。很多NoSQL后来遇到“嵌套查询难”的问题，根源就在这里。
再提一下键。超键（super key）是能唯一标识一个元组的属性集合；候选键（candidate key）是最小的超键，删除任何一个属性就不再具备唯一性；主键（primary key）是从多个候选键中挑选出来代表该关系的那个。外键（foreign key）则是引用另一关系主键的属性集，它是引用完整性规则的载体。
这三套概念（结构、完整性、操作）里，完整性规则特别容易被开发忽略。实体完整性要求主键不能为空，因为空值无法标识一个实体；引用完整性要求外键要么为空，要么必须对应被引用关系的实际元组，否则就会出现“孤儿记录”。很多业务系统出现脏数据，回头查，多是没有认真设计外键约束，或者干脆在应用层自己维护引用关系导致漏判。
2. 关系代数基础算子：五朵金花与它们的意义
关系代数是一种过程性查询语言：你告诉系统“先做什么，再做什么”，每一步用一个算子，最后得到结果。它由一组封闭运算构成，输入是关系，输出还是关系。这种封闭性是极其重要的设计——它意味着运算结果可以继续作为下一个运算的输入，像管道一样拼接出任意复杂的查询。
2.1 选择（Selection）与投影（Projection）：一横一纵两个基本动作
选择算子，符号为σ，读作“sigma”，定义是：从关系 R 中选出满足条件 C 的元组。用数学写是 σ_C(R) = { t | t ∈ R ∧ C(t) }。它做的是“横向筛选”，也就是过滤行。日常SQL里的WHERE子句，对应的几乎都是选择。
举一个例子。假设员工表 emp(name, dept, salary, age)，查询研发部且薪资大于20000的员工：
σ_{dept='研发' ∧ salary>20000}(emp)
优化器在做这一步时，会判断表上有没有可用索引。如果 dept 有索引，可能先走索引定位到研发部所有人，再过滤薪资；如果选择性太低，比如研发部占全表80%，那还不如直接全表扫一遍。你会看到执行计划里出现Filter节点或Index Seek节点，本质都是在执行“选择”。
投影算子，符号为π，读作“pi”，定义是：从关系 R 中选出属性列表 L 对应的列，并去除结果中的重复元组。π_L(R) = { t[L] | t ∈ R }。它做的是“纵向裁剪”。SQL里的SELECT后面的列清单，对应的就是投影。
需要注意的一点是：投影在数学上会去重。比如只查部门列，结果里不会出现两个相同的部门。但SQL默认不会去重，你要手动加DISTINCT才符合投影语义。为什么会这样？因为SQL为了性能和实用主义，放宽了集合语义，把关系变成了多集合（bag）。这个差异在生产环境会带来分页、计数、连接时的各种“意料之外”，后面我会专门写。
选择与投影经常组合使用。例如，先选择再投影，还是先投影再选择，在关系代数里有交换律：σ_C(π_L(R)) = π_L(σ_C(R))，前提是条件C用到的列都在L里。优化器会利用这种等价关系调整算子顺序，尽量早做选择、早做投影，缩小中间结果集，降低IO和内存开销。这就是“谓词下推”的理论依据之一。
2.2 集合运算：并、差、交与它们的相容性约束
关系代数的集合运算包括并（∪）、差（−）、交（∩）。它们和平常集合论里的运算含义一致，但有一个关键前提：参与运算的两个关系必须是并相容的（union-compatible）。具体说就是属性个数相同，对应位置的属性出自同一个域。
为什么要有这个约束？因为如果不规定属性数量和取值域一致，那么“把两个关系的元组合并成一个集合”这件事在语义上就是混乱的。比如，一张表是(姓名, 电话)，另一张表是(姓名, 城市)，两者直接做并集，每一行的第二列到底是电话还是城市？会产生歧义。
SQL里的UNION、EXCEPT、INTERSECT就对应这三个算子，并且也有类似约束：列数相同，列类型兼容。在写SQL时如果两个子查询的列顺序不一致，数据库不会帮你纠正，会把错误的结果或报错抛回来。
这些算子在实际场景中很有用。比如，对比两个环境下的用户表差异：全量A与增量B之间做差，就能得到“已注销用户”的集合；两张历史快照之间做交集，可以找到“始终存在的实体”。我在做数据对账时经常用EXCEPT来快速找两批数据之间的不一致，比写各种JOIN加IS NULL条件直观得多。
2.3 连接（Join）：关系模型表现力的核心来源
连接是把两个关系按某种条件组合起来，生成一个新关系。这里有几个关键变体。
笛卡尔积（Cartesian product，符号×）：不加任何条件，把R的每个元组和S的每个元组都拼一遍。如果R有m行，S有n行，结果就有m×n行。SQL里的CROSS JOIN或者FROM R, S不带WHERE，都是笛卡尔积。实际开发中，漏写连接条件导致的“笛卡尔积爆炸”，是慢查询的经典源头之一。
等值连接（equijoin）：连接条件是两个属性的值相等。如果连接条件是多个，就是复合等值连接。SQL里最常见的JOIN ON a.id = b.id，本质上就是这个。
自然连接（natural join，符号⋈）：一种特殊的等值连接，它会自动把两个关系中所有同名的属性做相等比较，并在结果中去掉重复的同名列。自然连接的好处是简洁优雅，坏处是“隐式依赖属性名”，一旦两边把同名列改个名字，语义就悄悄变了。工程上我更建议用显式的JOIN ON条件，可读性更好，也不容易踩坑。
从关系代数角度看，还有一个重要的理解：连接可以由笛卡尔积+选择推导出来。R ⋈_C S 等价于 σ_C(R × S)。理论上你只需要笛卡尔积和选择就够了，但连接作为一个独立算子被保留，是因为它太常用了，值得单独优化。数据库里往往有专门的HASH JOIN、NESTED LOOP JOIN、MERGE JOIN算法，它们都对应这个算子，而不是傻乎乎做笛卡尔积再过滤。
真正理解等值连接和自然连接的区别，能帮你诊断SQL问题。比如两表JOIN，如果你写的ON条件遗漏了一部分，结果可能产生重复行——本质上就是因为连出来的结果里有冗余组合。这种重复不是数据错了，而是你的连接条件没有把元组唯一对应起来。这种问题在数学上等价于：你没让两个关系在足够多的属性上做匹配，导致一个左元组对应了多个右元组。
3. 扩展算子：解决基本代数表达不了的工程问题
基础五朵金花（选择、投影、并、差、笛卡尔积）已经具备完备的表达能力，但它们用起来很笨拙。比如“按部门统计平均工资”，基本代数表达不出来，因为缺少“分组聚合”的机制。所以关系代数在实际应用里通常还会扩展出更名、赋值、分组、聚合这些算子。
3.1 更名与赋值：让复杂表达式变得可读、可复用
更名算子ρ（rho）的作用是给关系或属性换名字。比如ρ_{emp2(dept, avg_sal)}(emp)，把结果的关系名和列名都换掉。为什么需要它？因为复杂查询需要分步计算，每一步生成新的关系，再作为下一步的输入。没有更名，你无法在后续运算中索引到上一步的列名。
赋值运算（assignment，符号←）类似编程语言里的赋值语句。把中间结果赋给一个临时关系名，然后继续写后续运算。这个机制让关系代数表达式在纸上可读性更高，也让我们在做手工推算时能把复杂查询拆成一串简单步骤。
在工程对应关系上，更名和赋值对应了SQL里最常见的两种模式：子查询的别名和CTE（WITH语句）。尤其是CTE，它把你查询中的某一个逻辑块显式命名，后续反复引用。无论是PostgreSQL还是MySQL 8.0，优化器在处理CTE时也往往会对它做物化或内联优化，这与关系代数“先算出一个中间关系、再基于它继续算”的思路一脉相承。
3.2 除法（Division）：几乎所有教科书都会讲、但工程里不如JOIN常用
除法算子（÷）解决的问题是“那类”查询：找出与某个集合中所有元素都有关联的那部分元组。最经典的例子是“找出选修了所有课程的学生的名单”。
基本思想可以这么理解：给定关系R（选课记录：学号、课程号）和关系S（全部课程列表：课程号），R ÷ S 的结果是所有R中出现的学号，并且每个学号在R中所关联的课程号集合，必须完全覆盖S中所有课程号。
工程上，这种“全称量化”查询通常用反连接或GROUP BY + HAVING COUNT(DISTINCT ...)来实现。很多开发第一反应是子查询套子查询，写出来又长又慢。理解了除法语义，你能更清醒地判断一条“覆盖所有”的查询本质上需要做两层逻辑：先算每个候选对象覆盖了多少目标对象，再和目标总数做比较。
不过坦白说，在真正做工程时我用到除法的场景并不多。多数“覆盖式”查询用LEFT JOIN + IS NULL扣掉“不满足”部分会更高效。但理解除法的语义依然有用，特别是在面试或算法题里，你能一眼看出它在表达全称量词逻辑，避免写出错误的双NOT LIKE写法。
3.3 分组与聚合：从“行计算”到“列计算”的跨越
分组算子γ（gamma），形如 γ_{dept, AVG(salary)}(emp)。它的语义是：先把元组按指定属性分组，再对每个组应用聚合函数，生成一行结果。
这里有个容易混淆的点：关系代数的“基础”里是没有分组和聚合的，它们属于“扩充关系代数”。因为聚合函数（SUM、AVG、MAX、MIN、COUNT）处理的是组内的多个值，输出的是单一值，这本质上有“从集合到标量”的跳变。SQL里的GROUP BY正是这个算子的语法化身。
分组查询有一个常见的坑，就是“SELECT的列必须都在GROUP BY里”这条规则。从关系代数角度看它的原因很清晰：分组之后，组内的普通属性不再有确定的值，你不能拿组内某个元组的属性值和聚合结果拼在一行。但现实中包括PostgreSQL在内的一些数据库，允许了一种“功能依赖”的情形——如果你SELECT的列在分组列中存在函数依赖，比如按主键分组，那其他列可以带出来。这个功能正是关系模型键理论的直接产物。理解这一点，你就不会在SQL检查上盲目“一刀切”，能准确判断什么时候必须报错、什么时候合法。
排序（ORDER BY）在关系代数里也没有原生算子，因为它不是集合运算，而是打破了元组顺序无关性。所以SQL里的ORDER BY严格来说是数据库扩展的“显示功能”，不影响查询结果的集合语义。这也从侧面回答了一个问题：为什么子查询里ORDER BY常常没有意义，除非配合LIMIT。因为关系代数层面的运算并不尊重顺序，物理执行才关心它。
4. 关系代数与SQL：翻译关系、等价改写与优化联想
理解了关系代数，就能把一条SQL在心里“翻译”成一棵算子树，从而判断它的执行效率、能否改写优化。这层能力是区分“会写SQL”和“懂SQL”的关键分水岭。
4.1 从SQL到关系代数的核心映射
SQL语法和关系代数算子的对应关系大体如下表：
| SQL关键字/子句 | 对应关系代数运算 | 说明 |
|---|---|---|
| SELECT 列清单 | π 投影 | 若未加DISTINCT，允许结果中保留重复行，是“带多集合语义”的投影 |
| WHERE 条件 | σ 选择 | 横向过滤行，条件直接决定选择谓词 |
| FROM R, S / JOIN | × 或 ⋈ | 笛卡尔积或某种连接JOIN类型决定具体连接 |
| UNION | ∪ 并 | 默认去重（UNION ALL不去重） |
| EXCEPT | − 差 | 求差集 |
| INTERSECT | ∩ 交 | 求交集 |
| GROUP BY + 聚合 | γ 分组聚合 | 分组键与聚合函数共同决定 |
| DISTINCT | 去重运算 | 在关系代数中“集合”本身自带去重，SQL需要显式指定 |
| ORDER BY | 排序扩展 | 非关系代数原生算子，是SQL的显示层扩展 |
| LIMIT/OFFSET | 无直接对应 | 物理分页操作，不属于集合运算 |
这一张表对日常排查慢SQL特别有用。我遇到过高频场景：一条查询里先用了WHERE过滤出几百行，然后JOIN了几百万行的明细表。翻译成关系代数，就是执行计划选中了大表作为驱动表，做了不划算的NESTED LOOP JOIN。因为“WHERE过滤”是一个高选择性的σ，它应该被下推到去扫描小结果集；但如果你在写SQL时不注意子查询层面的过滤时机，优化器有时无法自动帮你把过滤下去。这时候手动改写SQL，把过滤操作提前，通常能显著提速。
4.2 等价改写：为什么优化器能帮你“调顺序”
关系代数有一整套等值变换规则，优化器依赖它们来推算代价更低的执行计划。最常用的是这几条：
- 选择下推：σ_C(R ⋈ S) 等价于 σ_C(R) ⋈ S，如果C只涉及R的属性。转化后，R先被过滤变小，连接输入更小，IO更少。
- 投影下推：把π尽早放到算子下层，减少传递列数。
- 选择与投影合并：σ和π相邻时可以合并成带过滤的投影，减少一次算子节点。
- 连接结合律：某种情况下连接顺序可以调整，(R ⋈ S) ⋈ T 与 R ⋈ (S ⋈ T) 不等价，因为中间结果大小不同。优化器会评估多种连接顺序，选代价最小的。
- 外连接与选择：条件涉及可空补充表时，选择不能简单下推，否则会丢结果。
理解这些规则，最大的实际收益是判断“要不要自己动手改写SQL”。比如查询里有子查询套子查询，如果优化器把它们重写为连接并下推过滤，你没必要自作聪明提前物化；但如果优化器没有做下推，你等待的时间就是白白付出的成本。我的建议是：拿到慢查询，先EXPLAIN看执行计划，看它把σ放在哪个位置。如果过滤没有下推到扫描底层，就是你该出手改SQL的信号。
4.3 笛卡尔积陷阱：关系代数视角下的典型事故
笛卡尔积本身是合法算子，但它是所有连接意外中最可能出现性能灾难的场景。很多人写JOIN时漏掉ON条件，或在子查询里少写了连接谓词，数据库就会先做笛卡尔积再去过滤，中间结果瞬间爆炸。
用关系代数来理解这件事特别直观：R × S 的中间结果大小等于 |R|×|S|。如果两个表都是百万行，中间就会生成一万亿行，任何机器都扛不住。有些执行计划虽然最终会通过选择把大部分行过滤掉，但生成中间结果的过程已经把内存和临时文件写满了。
实战里有一个典型的“LEFT JOIN外翻”问题。关系代数里外连接并没有被完全包含在基本运算中，SQL的LEFT JOIN / RIGHT JOIN是扩展功能。优化器处理外连接时，连接顺序受到比内连接更大的限制——你不能简单地把右表和左表交换，因为那样会改变“保留侧”的语义。这就是为什么有些慢查询，你用INNER JOIN的逻辑去换顺序有效，换成LEFT JOIN就不一定了，而且可能还会把结果改错。
5. 工程实战中的关系模型：索引、规范化、以及我踩过的坑
理论讲完了，落回工程。关系模型不只是一套纸面数学，它的设计理念渗透在现代数据库里，方方面面影响你写表和写查询的方式。
5.1 索引与实体完整性：为什么主键不该随意改
关系模型的实体完整性要求主键非空且唯一。工程落地时，主键通常会成为聚簇索引的键或唯一索引的依托。经常有开发问：主键用自增ID还是UUID？从关系代数层面没法回答“哪种性能好”，但从实体完整性角度看，你只需要一个能稳定标识元组、永不变化的键。自增ID短小精悍，索引占用小；UUID全局唯一，适合分布式但随机分布会带来写放大。各有利弊，核心是选定后别改。一旦主键失效或改变，关系模型依赖的引用完整性就会被破坏，外键关联也会跟着出问题。
我实际见过一个事故：某团队为了“隐藏真实主键”，把业务编号当主键，后来业务方要求编号可改，他们直接在UPDATE里更新主键，导致历史订单的外键指向了错误记录。从关系模型角度看，这违反了“主键不应当承担可变业务含义”的设计原则。候选键和主键的职责是标识实体，不是承载可变的业务状态。业务编号应该作为普通候选键，加上UNIQUE约束，主键用自增或ID就好。
5.2 规范化：函数依赖与更新异常
关系模式的规范化理论建立在函数依赖（functional dependency）之上。语义是：若属性集合X的值确定后，属性集合Y的值也唯一确定，则称X函数决定Y，记作X→Y。函数依赖是键的概念的一般化。候选键就是能函数决定所有其他属性的最小属性集。
第一范式（1NF）要求属性原子化；第二范式（2NF）要求消除非主属性对候选键的部分函数依赖；第三范式（3NF）要求消除非主属性对候选键的传递函数依赖；BCNF进一步消除主属性对候选键的部分和传递依赖。这些都是为了减少更新异常（插入异常、删除异常、修改异常）。
工程上有一个很现实的争论：要不要为了查询性能做冗余设计（反规范化）。关系模型给你的答案是：先按范式设计出干净的结构，确保数据一致性，再在有明确性能瓶颈处做受控冗余。冗余的数据往往需要靠应用层保证同步，一旦同步逻辑遗漏，就是对模型完整性的破坏。所以每做一次反规范化，你都要问自己：我能接受这个冗余字段在极端情况下不一致吗？如果不能，就不要做，或者加好定时补偿机制。
5.3 SQL与关系代数的多集合差异：DISTINCT和分页的真相
前面反复提到SQL里关系实际上是多集合（bag），不是集合。这个差异在日常开发中制造的坑非常隐蔽。
举个典型场景：一个订单表和一个订单明细表连接，统计“下单客户数”。因为一张订单有多个明细，JOIN之后一个客户会出现在多行，这时COUNT(*)得到的是行数，不是客户数。很多人没意识到问题，直出重复计数。用关系代数的眼光看，你真正需要的是“对连接结果去重后的基数”，也就是COUNT(DISTINCT customer_id)。这个差异在数据报表里比较致命，我见过不止一次周报数据虚高，最后定位就是JOIN引发的膨胀。
另一个坑是分页。LIMIT 10 OFFSET 1000000在大表上往往奇慢，因为数据库需要先找到第100万行再跳过。用关系代数表示分页，它根本不是一个集合运算，而是物理层面的窗口定位。优化器无法对OFFSET做太多数学优化，所以它的性能上限受限于物理扫描。解决方案往往靠游标分页（基于上次最大ID继续取）或基于ROW_NUMBER的窗口函数，本质上是用新的数学结构来规避关系代数无法优化的天然缺陷。
5.4 优化器与关系代数：为什么执行计划是“一棵树”
理解了关系代数，看EXPLAIN输出就不再玄学。执行计划本身就是一个关系代数表达式树：叶子节点是表扫描（全表扫描、索引扫描、索引回表），中间节点是选择、投影、连接、聚合，根节点是最终输出。优化器做的事情，就是在等价变换规则范围内，生成一个代价最小的算子树。
所以当你看EXPLAIN时，你最关心的几个问题都对应算子：
- 有没有出现大量行数的扫描（Table Scan / Seq Scan）？叶子节点的行数过大，通常意味着选择没有下推。
- 连接算法是哪种？HASH、NESTED LOOP还是MERGE？代价特征各不相同。
- 有没有出现临时表或Sort节点？Sort在关系代数里是额外开销，能避免就避免。
- 有没有重复计算？子查询被物化还是被内联？
我曾经处理过一个慢查询：两张千万级表JOIN，还带一个复杂的LIKE条件。优化器选择了NESTED LOOP JOIN，估算约一小时。我手动改写为一个IN子查询和一个EXISTS子查询，配合索引，执行时间降到十几秒。事后分析，改写后的执行计划正好对应了一棵“先做高选择性选择，再连接小结果集”的算子树——这正是关系代数里选择下推原则的具体应用。
6. 几个值得记住的实操心得
写到最后，分享几条我在实际工作中积累的体会。
第一，写SQL前先在脑中翻译一遍“关系代数步骤”。不管查询多复杂，先问自己三个问题：需要从哪些表取数据？需要如何组合这些表？组合后需要过滤什么、按什么分组、保留哪些列？这个过程会自动帮你梳理逻辑，也能提前暴露“漏了连接条件导致笛卡尔积”的低级错误。
第二，用集合思维而不是编程思维写SQL。做数据分析时，比如“找出所有没有订单的用户”，用LEFT JOIN + WHERE IS NULL，或者用NOT EXISTS，比先把有订单的用户循环查出来再在代码里比较列表要高效得多。别把数据库当“逐行遍历的循环”，它就是一套声明式的集合运算。
第三，诊断慢查询时优先看“选择有没有下推”。我见过太多开发拿到慢查询第一时间想去加索引，但其实索引只是物理手段，有时候几天前写SQL时的JOIN顺序和过滤位置才是根因。先用执行计划确认哪里生成了过大的中间结果集，再决定是否加索引或改写SQL，这个顺序不应该反过来。
第四，要正确认识关系模型与SQL的关系。SQL关心的是易用性，它允许重复行、允许乱序、允许各种非关系模型的语法糖。关系模型关心的是严谨的数学基础。两者之间存在缝隙，这个缝隙恰恰是大多数SQL“意外结果”的来源。所以当你遇到SQL结果和预期不一致时，先问自己：我期望的到底是“多集合语义”还是“集合语义”？可能需要一个DISTINCT，可能需要一个分组去重，也可能需要重新设计连接条件。
关系模型诞生半个世纪了，今天各种数据库形态百花齐放，但在事务型关系数据库这个领域，理论根基依然稳固。我每次遇到难解的查询或优化问题，回到关系代数层面重新梳理，几乎都能找到清晰的解决思路。它是那种“学了看似用不上、其实天天在替你打工”的基础工具，值得每个数据库从业者认真吃透。
