做数据库实验最怕的不是写不出来 SQL，而是写出来之后不敢确定对不对。尤其是连接查询这一块，等值连接、非等值连接、外连接、自连接看起来每个词都认识，真正落到 navicat 或者命令行里面一执行，出来的结果经常让人当场愣住。这次实验报告的核心就是数据查询里的连接应用，我把一个模拟选课系统的完整场景从头到尾跑了一遍，把连接查询的选型思路、SQL 写法、坑点和排查方法都整理出来了。如果你是正在学数据库原理、准备期末上机或者刚接触多表查询的开发者，这篇内容可以直接拿来参考复现，我也尽量把“为什么这么写”讲清楚，而不是只给你一堆能跑但看不懂的语句。

1. 这次实验到底在练什么：场景设计与表结构说明

1.1 为什么连接查询是数据查询的核心难点

关系型数据库的设计前提就是“拆表”：尽量减少冗余，把数据按业务主题拆成多张独立的表。学生信息放一张表，课程信息放一张表，谁选了哪门课又放一张关联表。这是规范化的好处，但它带来的直接代价就是——当你想一次性查出“张三选了数据库原理且成绩是多少”这种跨表信息时，就必须把多张表重新装配起来，这个装配动作就是连接（JOIN）。

很多初学者觉得连接难，是因为理解层面停留在“把表拼在一起”的模糊感觉上，没有真正建立起笛卡尔积、连接条件和结果集这三个概念。我在做实验之前也是凭感觉写，遇到 LEFT JOIN 和 WHERE 混用的时候经常翻车。后来发现，只要把 SQL 的执行顺序和连接的工作方式弄明白，连接查询的难度会瞬间降下来。

这一节先做场景设计：以一个模拟高校选课系统为实验对象，使用三张表——学生表 student、课程表 course、选课表 sc。三张表的关系是经典的一对多：一个学生可以选多门课，一门课可以被多个学生选，sc 表通过 sno 和 cno 两个外键把学生和课程关联起来。为了做非等值连接实验，我额外加了一张成绩等级表 grade_level，用分数区间映射等级。这个场景在几乎所有数据库教材里都有原型，但我会刻意把实验记录写得贴近实际操作，而不是照抄教材。

1.2 三张核心表的建表与数据准备

建表是连接查询的地基，字段类型不一致、主外键缺失、数据重复这些问题都会在 JOIN 之后被放大。我实验环境使用的是 MySQL 8.0，字符集统一用 utf8mb4，避免后续字符串比较出现编码不一致的诡异结果。

学生表设计如下：

CREATE TABLE student ( sno CHAR(9) PRIMARY KEY, sname VARCHAR(20) NOT NULL, ssex CHAR(2), sage SMALLINT, sdept VARCHAR(20) );

课程表多设计了一个 cpno 字段，表示先修课程的编号。这个字段是关键，后面做自连接就靠它：

CREATE TABLE course ( cno CHAR(4) PRIMARY KEY, cname VARCHAR(40) NOT NULL, cpno CHAR(4), -- 先修课程编号 ccredit SMALLINT );

选课表是连接查询的核心桥梁：

CREATE TABLE sc ( sno CHAR(9), cno CHAR(4), grade DECIMAL(4,1), PRIMARY KEY (sno, cno), FOREIGN KEY (sno) REFERENCES student(sno), FOREIGN KEY (cno) REFERENCES course(cno) );

成绩等级表用于非等值连接：

CREATE TABLE grade_level ( level_name VARCHAR(10), low_score DECIMAL(4,1), high_score DECIMAL(4,1) ); INSERT INTO grade_level VALUES ('优秀', 90, 100); INSERT INTO grade_level VALUES ('良好', 80, 89.9); INSERT INTO grade_level VALUES ('中等', 70, 79.9); INSERT INTO grade_level VALUES ('及格', 60, 69.9); INSERT INTO grade_level VALUES ('不及格', 0, 59.9);

这里有个细节：grade 字段我用的是 DECIMAL(4,1) 而不是 INT，因为成绩可能带小数。很多人建表的时候图省事用 INT，后面做聚合查询 avg(grade) 时精度直接丢了，还要再 cast，纯属给自己挖坑。

插入测试数据的时候，我刻意留了几个特殊数据：一名学生没有选任何课程；一门课程没有任何学生选；另有一个学生的某个选课记录成绩为 NULL。这三条“边界数据”在普通查询里看不出问题，但连接查询里它们就是照妖镜，能不能正确处理 NULL 和空集，直接反映了对连接语义的理解深度。

插入数据的语句这里不完整展开，但最后你可以执行 SELECT * FROM student; 等语句确认每张表至少 5 条以上有效记录，尤其是 sc 表要覆盖不同课程、不同年级、不同成绩段，这样后面做聚合和等级映射才有说服力。

2. 连接查询的类型拆解：到底该用哪一种

2.1 INNER JOIN：最常见但最容易忽略行数变化

INNER JOIN 也叫内连接，它只保留满足连接条件的记录。它有两种常见的等价写法：

-- 方式一：显式 JOIN 语法 SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s INNER JOIN sc ON s.sno = sc.sno; -- 方式二：隐式连接（老式写法） SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s, sc WHERE s.sno = sc.sno;

两者执行结果一样，但我更推荐显式 JOIN 语法。原因不只是可读性问题：隐式连接把连接条件和过滤条件混在 WHERE 里，如果后来追加过滤条件，很容易丢 WHERE，把一个等值连接变成笛卡尔积，这是实验里最容易出的致命错误。显式写法把 ON 和 WHERE 的职责分开了，安全系数明显更高。

等值连接是最常见的情况，就是连接条件里用等号。非等值连接则是连接条件里使用比较运算符或 BETWEEN 这类范围判断。举一个实际例子，我想做一张“学生成绩等级对照表”，普通思路是嵌套 CASE WHEN，但如果我建好了 grade_level 表，直接这样连接就行：

SELECT s.sname, sc.grade, gl.level_name FROM sc INNER JOIN student s ON sc.sno = s.sno INNER JOIN grade_level gl ON sc.grade BETWEEN gl.low_score AND gl.high_score ORDER BY sc.grade DESC;

这就是典型的非等值连接——ON 条件不是相等，而是范围命中的关系。连接不只有“等于”这一种语义，凡是能把两张表的记录按某种规则配对的操作都可以称为连接。理解这一点之后，看待 JOIN 的眼界就不会局限于外键等值匹配了。

关于 INNER JOIN 的结果行数，有一个高频易错点：多对多关系下结果集会膨胀。比如一个学生选了 3 门课，student JOIN sc 之后这个学生会对应 3 行而不是 1 行。如果你预期的粒度是“一个学生一行”，而实际表结构是“一个学生多行”，那就需要在连接后做聚合或者调整连接粒度。我在实验里统计学生选课门数时就碰到这个问题，一开始直接 select count(*) 出来是 12，拆开看才知道是连接后行数放大了，最后加上 group by 才拿到正确结果。

2.2 LEFT / RIGHT JOIN：什么时候必须用外连接

外连接解决的核心问题是：连接条件不满足时，仍然希望保留一侧表的全部记录。LEFT JOIN 保留左表全部行，右表没匹配上的地方填 NULL；RIGHT JOIN 恰好相反。

我实验里有两个典型场景必须用外连接。第一个是“查出所有学生的选课情况，没选课的学生也要列出来”：

SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s LEFT JOIN sc ON s.sno = sc.sno ORDER BY s.sno;

这条语句跑出来，没选课的那名学生会在 cno 和 grade 列显示 NULL，但他本人不会消失。如果用 INNER JOIN，这名学生就整个被过滤掉了，业务语义上等于“没有选课记录的学生不参加统计”，这在某些场景是对的，但和“全部学生都要列出来”的需求就不符了。

第二个场景反过来：统计每门课程的选课人数，没人选的课也要出现在结果里。这里我用 LEFT JOIN 把课程表放在左边：

SELECT c.cno, c.cname, COUNT(sc.sno) AS 选课人数 FROM course c LEFT JOIN sc ON c.cno = sc.cno GROUP BY c.cno, c.cname ORDER BY c.cno;

注意这里 count 的是 sc.sno 而不是 count()——为什么？如果 count()，没被选中的课程那一行也会被计入 1 人，因为 LEFT JOIN 后该课程记录仍然存在，只是右侧字段是 NULL。count(具体列) 会忽略 NULL，count(*) 不会。这个小差异就是很多实验结果“差一行”的根源。

MySQL 8.0 不支持 FULL OUTER JOIN，所以如果需要“学生和课程的完全外连接”效果，标准做法是左外连接 UNION 右外连接。考虑到实验场景很少真的需要这种效果，我就在概念上了解了一下，实操里没有强行造场景。

2.3 自连接与交叉连接：越冷门越容易在实验里加分

自连接是表和自己做连接，很多教材只是提了一嘴，但实际应用非常广。比如课程表里的先修课程字段 cpno，它是指向 course 表自身 cno 的外键。想查询“每一门课程的直接先修课程名称”，就得把 course 表当成两张表来用：

SELECT c1.cname AS 课程名, c2.cname AS 先修课程 FROM course c1 LEFT JOIN course c2 ON c1.cpno = c2.cno ORDER BY c1.cno;

LEFT JOIN 在这里是刻意的，因为可能有课程没有先修课，cpno 为 NULL 时，用唯一表别名区分。

自连接的关键是给同一张表起两个不同的别名，让数据库认为它们是两个独立实体。忘了写别名或两个别名用同一个，会直接报语法错误。另外自连接也要小心行数膨胀，如果连接条件写得宽泛，比如只要 c1.cno > c2.cno 就能产生大量配对，这在某些组合问题上是有意的（比如求所有课程两两组合），但如果只是想找先修关系，连接条件必须精确命中 cpno 和 cno 的对应关系。

交叉连接 CROSS JOIN 是另一种极端：不带任何连接条件，直接生成笛卡尔积。实验里我专门试了一下：

SELECT s.sno, s.sname, c.cno, c.cname FROM student s CROSS JOIN course c;

学生 6 人、课程 5 门时，结果直接出来 30 行。交叉连接在日常业务中几乎不会独立使用，但理解它非常重要——因为所有 JOIN 都是先在逻辑上做笛卡尔积，再用 ON 条件筛选，如果漏写 ON，数据库不会报错，而是默默返回一个巨大且无意义的结果集。实验现场最容易翻车的就是这种“SQL 没红、结果全乱”的情况。

3. 完整实操：从单表到多表连接的 SQL 实现

3.1 两表连接的完整实验记录

我先把两表连接的过程完整跑了一遍，分别是“学生-选课”和“课程-选课”两组。这一小节的语句比较简单，但我会配合执行顺序来说明它们内部是怎么运作的。

第一条是标准内连接，语句如下：

SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s INNER JOIN sc ON s.sno = sc.sno;

执行原理拆开看，是这么三步：先做 student 表与 sc 表的笛卡尔积，然后根据s.sno = sc.sno把不满足的行删掉，最后投影出 SELECT 里指定的列。虽然实际数据库会用索引优化这个过程，逻辑上可以这样理解。执行之后的结果里，一个学生选了几门课就会出现几行，这个预期要在实验报告里写明，否则看着结果容易自我怀疑。

第二条是查询所有课程及其被选修情况，我用的是把课程表放在左侧的 LEFT JOIN：

SELECT c.cno, c.cname, sc.sno, sc.grade FROM course c LEFT JOIN sc ON c.cno = sc.cno;

执行后能看到没人选的课程那一行 sno 和 grade 全为 NULL。建议你在自己的实验里专门数一数 NULL 行数，体会 LEFT JOIN 的“保留左侧全部”语义。

第三条是用非等值连接做成绩等级查询，也就是前面 2.1 里那条语句。这里我再细说一下执行过程：sc 表先与 student 表按学号等值连接，把学生姓名带出来，然后结果集再与 grade_level 表做范围匹配。grade 为 85.5 的记录会落在BETWEEN 80 AND 89.9的区间里，得到“良好”等级。这里有个边界问题需要特别注意：grade 正好等于 89.9 时，既满足< 89.9的“良好”区间上限，还是已经达到 90？我在实验里把 grade_level 的 high_score 设成本区间最大值、而下一个区间的 low_score 设成该值加 0.1，就是为了避免同一分数命中两个等级。

做这些两表连接实验时，建议每跑完一条语句就顺手记录结果行数，尤其是和原始表行数对比。比如 student 有 6 行，sc 有 12 行，那么 student INNER JOIN sc 的结果行数应该是 12 而不是 6，因为每个选课记录都对应一个学生。行数和预期不一致时，下一步排查连接条件基本不会错。

3.2 三表连接：学生-选课-课程怎么串起来

两表连接只是热身，实验的核心是三表及以上连接。例如同时输出“学号、学生姓名、课程名、成绩、学分”这样既跨学生又跨课程的查询，必须把 student、sc、course 三张表串在一起。

串表的关键是选好“桥表”：sc 表既是选课事实表，又是 student 和 course 之间的桥梁。正确的写法是：

SELECT s.sno, s.sname, c.cname, sc.grade, c.ccredit FROM student s INNER JOIN sc ON s.sno = sc.sno INNER JOIN course c ON sc.cno = c.cno ORDER BY s.sno, c.cno;

这个连接顺序是从带条件的表开始的：先 student 连接 sc，再把结果连接 course。实际上数据库优化器会自己调整执行顺序，但写语句的时候，让逻辑顺序清晰能减少很多思考负担。三条连接条件的顺序也有讲究：sc.sno连接s.sno，sc.cno连接c.cno，中间都是以 sc 为基准展开的。我自己写多表连接时，习惯先写事实表，再顺着外键逐条往外扩，这样不容易漏条件。

三表连接如果业务条件比较多，最好把过滤条件写清楚。比如查询“选修了数据库原理且成绩不低于 90 分的学生名单”：

SELECT s.sname, c.cname, sc.grade FROM student s INNER JOIN sc ON s.sno = sc.sno INNER JOIN course c ON sc.cno = c.cno WHERE c.cname = '数据库原理' AND sc.grade >= 90;

按查询逻辑，先对 sc 表过滤出满足条件再与其他表连接，不要先连接出大结果再过滤。SQL 里 WHERE 在逻辑上是 JOIN 之后执行的，但如果数据库优化器经过等价改写，也会先把过滤条件下推，所以写法上不用担心性能。以下几个 WHERE 条件可以放进 ON，也可以放进 WHERE，效果和性能通常一样。过滤条件下推对性能的影响我放到第 4 节详说。

三表连接还有一个容易忽略的细节：多个连接方向从左到右时，如果中间某一步得到的结果集有重复，最终结果也会被放大。比如 student 和 sc 按学号连接时，某学生选了三门课，就有三行，再和 course 连接，如果前面不小心用错连接条件和字段，比如把sc.cno = c.cno写成s.sno = c.cno，就会产生大量不对的笛卡尔积内容，且结果行数暴涨。我在实验里故意写错过一次这个条件，出来的结果里学号与课程名完全错位，一眼就能看出来不对，但是行数往往不会少，所以千万别拿“有结果”当“结果对”。

3.3 连接查询与聚合函数、排序分页的配合

连接查询很少单独用来做展示，更多是配合聚合函数做统计报表。学生选课系统里最常用的统计就是“每门课程的选课人数和平均分”。我用 LEFT JOIN 加 GROUP BY 实现了这个需求，下面这条语句是实验里反复用到的基础模板。

SELECT c.cno, c.cname, COUNT(sc.sno) AS 选课人数, COALESCE(AVG(sc.grade), 0) AS 平均分, COALESCE(MAX(sc.grade), 0) AS 最高分, COALESCE(MIN(sc.grade), 0) AS 最低分 FROM course c LEFT JOIN sc ON c.cno = sc.cno GROUP BY c.cno, c.cname ORDER BY 选课人数 DESC, c.cno ASC;

COALESCE 是 ANSI 标准函数，在 MySQL 里也支持，作用是把 NULL 转成 0，避免没学生选的课程平均分显示为 NULL 而被报表程序读成异常值。

这里我踩过一个很经典的坑：GROUP BY 后面只写了 c.cno，没写 c.cname。如果 MySQL 开启了 ONLY_FULL_GROUP_BY 模式（MySQL 5.7 之后默认开启），SQL 直接报错；如果没开启更麻烦——它会随机挑一个 cname 出来，结果在数据不一致时根本对不上。所以凡是 SELECT 里出现的非聚合列，必须全部写进 GROUP BY。这个规则我每次都当顺口溜记着：select 非聚合，group by 全带上。

排序和分页在连接查询里同样常见。列出成绩从高到低的选课明细，分数前 5 名的记录用分页取出，语句如下：

SELECT s.sno, s.sname, c.cname, sc.grade FROM sc INNER JOIN student s ON sc.sno = s.sno INNER JOIN course c ON sc.cno = c.cno WHERE sc.grade IS NOT NULL ORDER BY sc.grade DESC LIMIT 5;

注意分页前我加了WHERE sc.grade IS NOT NULL，因为外连接实验中 sc.grade 存在 NULL 值，排序时 NULL 在 MySQL 默认排在最前面。如果不做过滤，LIMIT 5 会把 NULL 成绩的记录排进“前五”，那这个排名就没有意义了。成绩类的统计报表，NULL 过滤要成为肌肉记忆。

4. 实验中踩过的坑和排查实录

4.1 忘了连接条件的笛卡尔积事故

实验课上有位同学跑了两表连接，SQL 写了FROM student, sc，但 WHERE 条件漏了，结果返回 6 行加 12 行的乘积——72 行。第一反应是“这学生怎么选了这么多课”，仔细一看才知道是笛卡尔积。

笛卡尔积不报错，它只会静默地返回一个巨大的结果。要排查它，最直接的方法是观察结果行数：正常等值连接的输出行数不会超过两表行数的较小值太多（一对多时也不会超过事实表的行数），一旦远超合理范围，先检查连接条件是否存在。另一个排查技巧是在 SELECT 里临时加上主键字段，比如把 s.sno、sc.sno 都选出来，如果同一行里学号对不上，说明连接条件没生效或写错字段了。

连接条件漏掉的原因大多是从入门写法迁移到 JOIN 写法时习惯了“JOIN ON”结构，手一滑把 ON 中条件删了，SQL 也能跑通不报错。养成每次写完 SQL 先看执行计划、再顺手数一下行数的习惯，能在实验现场少掉很多头发。

提示：所有 JOIN 在逻辑上都是先做笛卡尔积再筛选。滤掉无效连接条件的核心手段就是确认 ON 子句完整、连接字段类型一致。

4.2 ON 与 WHERE 的语义差异：外连接中最隐蔽的坑

这应该是整个实验里含金量最高也最容易翻车的地方。我给一个具体场景：查询所有学生的选课记录，只需要课程号为 C001 的记录。有的同学会写成下面这样：

-- 错误示范 SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s LEFT JOIN sc ON s.sno = sc.sno WHERE sc.cno = 'C001';

这条语句的本意是“所有学生，只看选 C001 课的情况”，但实际结果是：只有选了 C001 的学生会被留下，没选 C001 的学生包括没选任何课的学生全被过滤了。为什么？因为 WHERE 在逻辑执行顺序上晚于 LEFT JOIN，它判断的是连接完成之后的结果集。对于没选 C001 的学生，LEFT JOIN 之后右表字段是 NULL，NULL = 'C001'的结果是 UNKNOWN，WHERE 判定为不满足，行被丢弃。这么一来整个查询就退化成了 INNER JOIN 之后再过滤，LEFT JOIN 完全失去意义。

那怎么同时保留所有学生，又只显示 C001 的记录？把条件挪进 ON 子句：

SELECT s.sno, s.sname, sc.cno, sc.grade FROM student s LEFT JOIN sc ON s.sno = sc.sno AND sc.cno = 'C001';

这个写法明确告诉数据库：连接时只匹配 C001 的选课记录，其他课程都视为未匹配，未匹配学生保留左表并置 NULL。ON 里加多个条件是合法的。

总结起来一句话：外连接里想过滤“被连接表”的字段，条件放 ON；想过滤“主表”的字段，放 WHERE 也可以——但注意放 ON 时主表的过滤条件可能会导致不符合预期的行。这个语义差异不是语法问题，是逻辑问题，SQL 不报错，结果就是你拿着完全错误的数据去写实验结论。我在实验报告里专门用了一小节记录这个对比结果，强烈建议你也亲手跑一遍错误和正确两个版本，观察结果集差异。

4.3 NULL 值处理：IS NULL 判空要谨慎

外连接必然会引入 NULL，紧接着就带来 NULL 判空的坑。最典型的需求是“找出没选过任何课程的学生名单”。正确写法是：

SELECT s.sno, s.sname FROM student s LEFT JOIN sc ON s.sno = sc.sno WHERE sc.sno IS NULL;

注意这里判断的是 sc.sno 为 NULL，而不是grade IS NULL。因为 sc.sno 是主键的一部分，它只有在没有匹配记录时才会是 NULL；而 grade 本身可能因为缺考就是 NULL，如果拿 grade 判空，会把“选过课但没成绩”的学生误判为“没选过课”。这个区分很容易被忽略，但含义完全不同。

同样，做“统计每个学生的选课门数”时，count 的字段也要考虑 NULL。选课门数是指选课记录数量，所以 count(sc.sno) 是安全的；如果错用 count(sc.grade)，那选过课但成绩为 NULL 的学生会被少算。实验里为了让这个问题暴露出来，我专门在 sc 表插入了一条 grade 为 NULL 的记录，运行结果立刻就不对了，排错过程比凭空讲一百遍都有效。

4.4 性能问题：连接字段该不该加索引

实验数据量小，性能问题感受不明显，但实验报告里还是应该把原理写到位。连接查询的性能核心在于“驱动表”和“被驱动表”的联系方式：MySQL 的默认连接算法是 Nested Loop Join，即从驱动表取一行，然后去被驱动表里找匹配行。如果被驱动表的连接字段没有索引，每次都要全表扫描，复杂度会从 O(N+M) 退化成 O(N×M)。数据量一上来，几百几千行时还没感觉，到百万级就是秒级和分钟级的区别。

理论上连接字段应该加索引，尤其是被驱动表那一侧的连接列。外键列通常都要建立索引，学生表的主键 sno 已有唯一索引，course 表主键 cno 已有唯一索引，sc 表复合主键 (sno, cno) 本身也有索引，所以三表连接里连接字段默认都是索引覆盖的，性能天然有保障。如果自己新建表，记住外键列要在建表时就加上索引。

另外一个工程层面的优化是过滤条件下推。假设我要查“计算机系学生选了哪些课”，写法 A 是先连接再过滤，写法 B 是先过滤出计算机系再连接。现代优化器通常会把写法 A 自动改写成“先过滤再连接”，所以语义正确的前提下，不用过度担心性能。但实验里自己手写时，先过滤后连接确实更稳妥，尤其遇到子查询时，提前缩小数据集对执行计划更友好。

最后说一个连接字段类型不一致的问题。如果一张表的 sno 是 CHAR(9)，另一张表的 sno 是 VARCHAR(20)，MySQL 连接时一方面索引大概率失效，另一方面还会做隐式类型转换。更阴间的是 CHAR 和 VARCHAR 尾部空格问题：CHAR 会自动去尾部空格，VARCHAR 不会，两张表同是 “S001”，一张存成 “S001 ” 就匹配不上。做连接之前，先把参与连接的字段类型、长度、格式统一好，这是最简单也最容易忽略的功夫。

4.5 常见错误速查表

为了写实验报告结论，我把这次实验遇到的典型错误整理成了一张表，供下次上机前快速自查。

这张表里的问题我基本都现场遇到过，第 2 条 ON 和 WHERE 的坑踩得最深，第 1 条笛卡尔积是身边同学问过最多的问题。实验课的意义就在于把这些“错误经验”变成判断直觉，下次看到结果集不对，心里自动有排查顺序。

5. 实验总结与实操体会

做完整个连接实验，我自己最大的感触是：连接查询从来不是“背语法”能解决的，核心是搞清楚结果集的粒度和连接条件的语义。写之前先想清楚三件事——目标结果里每一行代表什么粒度？需要用哪些表？这些表之间通过什么字段产生关联？只要这三件事理顺了，JOIN 写起来基本就是照抄结构。

另外一个小技巧说明：做连接实验时，我会从“不满足连接条件”的数据入手，比如故意插入一个没有选课的学生、一个没人选的课程、一条 NULL 成绩的记录。这些边界数据比一堆正常数据更能检验你的 SQL 到底理解没理解。一次实验如果有这三个边界数据的现象，报告写出来会很有说服力。我也建议你保留每一步的截图和行数记录，数据库实验报告的结论不是凭空写的，而是从这些原始观测数据里总结出来的。