数据库系统实验完整实操：从建表到SQL查询的避坑指南

数据库系统实验，是很多计算机相关专业学生都要过的一道坎。尤其是第一次做这类实验，不少人的状态都是：上课听懂了概念，打开命令行却不知道该先敲什么；或者建表语句都会，但一跑起来全是报错，改了半天发现是分号没加。这份“某邮电类高校数据库系统实验(1)”的内容，恰好在“基础SQL”和“数据库设计入门”之间找到了一个比较舒服的切入点，既不会难到让人无从下手，又刚好能把课程里那些藏在概念背后的东西逼着你亲手实现一遍。

这篇实验总结是我自己做完之后整理出来的，包含完整的设计思路、环境搭建、每一步的代码细节和参数选择理由，以及我在实际操作中踩过的坑和排查经验。如果你是正在做类似实验的同学，或者刚学SQL、想找个项目练手，这篇文章应该能帮你少走很多弯路。整个实验我分了几个核心模块来拆：任务怎么理解、环境怎么选、表结构怎么设计、数据怎么操作、异常怎么排查。下面我按实际推进的顺序，一件一件说。

1. 实验想考察什么：先是“读题”，再是“建表”

1.1 不要急着敲代码，先拆解任务书里的隐藏要求

数据库系统实验(1)这类题目，一般在任务书里会给出一个具体的业务场景，比如“学生选课系统”“图书管理系统”“员工考勤系统”之类，要求你用SQL完成从建库、建表，到增删改查的全流程。大多数同学容易犯的第一个错误，就是读题只读了个大概，看到“创建学生表”“创建课程表”就开写，结果漏掉了字段级的要求——比如某个字段要“唯一”，某个字段要“默认值”，某个表之间要“外键关联”，这些偏偏才是评分的关键点。

我当时拿到的题目场景是“学生选课管理”，涉及三个核心实体：学生、课程、选课记录。任务要求大致包括：

• 创建数据库，字符集要支持中文；
• 学生表包含学号、姓名、性别、出生日期、班级、入学年份；
• 课程表包含课程编号、课程名称、学分、授课教师；
• 选课表包含学生与课程的关联、成绩字段、选课时间；
• 完成至少6条以上的数据插入操作；
• 完成至少3条不同条件的查询（单表查询、多表连接查询、聚合查询）；
• 完成至少1次更新和1次删除操作；
• 所有表必须体现主键和外键约束。

这种任务本质上考察三件事：第一，你能不能把文字需求翻译成关系模型；第二，你能不能写出语法正确、约束完整的SQL；第三，你能不能通过实际操作验证自己的设计。所以做实验的第一步，不是装软件，而是在纸上或者文档里先把表结构草图画出来，想清楚每个字段的类型、长度、是否可空、默认值，以及表之间的关系。这一步看似浪费时间，实际上能帮你省下后面数倍的调试时间。

1.2 关系模型设计：从实体到字段的翻译过程

以“学生选课”为例，最基础的设计是三张表：学生表、课程表、选课表。实体之间的关系是“多对多”——一个学生可以选多门课，一门课可以被多个学生选，所以需要一个中间表（选课表）来拆解这个多对多关系。这个思路是关系型数据库设计的经典做法，也是实验里必考的点。

学生表的字段设计，我当时是这样取舍的：

• student_id：学号，用CHAR(12)或VARCHAR(12)，因为学号一般是定长字符串，用 CHAR 会比 VARCHAR 省去长度判断的开销；
• name：姓名，用VARCHAR(20)，中文字符按3字节计算，20个字符足够覆盖绝大多数姓名，但“VARCHAR(20)”的20是字符数不是字节数，这一点MySQL和Oracle的默认行为还不一样；
• gender：性别，用CHAR(1)或ENUM('M','F')，我用的CHAR(1)，存储上最省，逻辑也最简单；
• birth_date：出生日期，用DATE类型，不推荐字符串，因为字符串无法直接做日期函数操作，比如算年龄、查某个日期之后出生的学生都会很别扭；
• class_name：班级，用VARCHAR(20)；
• enroll_year：入学年份，用YEAR类型，比DATE更精确地表达“年份”语义，也方便按年份统计。

课程表的字段：课程编号、课程名称、学分、授课教师。学分用DECIMAL(3,1)，因为有些课程会有0.5学分的情况；授课教师用VARCHAR(20)。

选课表是设计重点，它承担两个外键和业务数据：

• student_id：引用学生表，外键约束；
• course_id：引用课程表，外键约束；
• score：成绩，用DECIMAL(5,2)，允许为空，因为学生选课后还没考试；
• select_time：选课时间，用DATETIME或TIMESTAMP，记录选课的精确时间点。

这里有一个特别值得注意的设计细节：选课表的联合主键。一张选课表如果不设主键，MySQL会允许插入重复的选课记录——同一个学生重复选同一门课，这在业务上叫“脏数据”。所以必须把(student_id, course_id)设成联合主键，这样数据库在物理层面就杜绝了重复选课。这个点很多同学会漏掉，但它恰恰是实验评分表里“完整性约束”那一栏的得分点。

2. 工具与环境选型：为什么我推荐MySQL 8.0 加图形化客户端

2.1 数据库引擎的选择：Direct与间接的成本评估

当前的数据库系统实验，主流选择其实就三个：MySQL、SQL Server、Oracle。很多学校机房装的是SQL Server，因为图形化界面做得好，建表操作可以全程鼠标点出来，教学演示方便。但我的建议是，如果学校没有硬性规定，优先选MySQL 8.0，理由有下面几条：

• 安装包小，Windows和macOS都有原生安装包，普通电脑跑起来毫无压力；
• SQL语法标准，学到的内容换到其他数据库基本能通用；
• 实验环境如果是Linux服务器，MySQL的适配性最好；
• 社区活跃，报错信息搜一下就能找到解决方案；
• 最关键的一点：MySQL 8.0 的窗口函数、CTE（公共表表达式）在后续实验里会用到，早适应比晚适应好。

如果用SQL Server或Oracle，语法上会有一些差异，比如字符串拼接的符号、分页的写法、自增主键的声明方式等。我不是说SQL Server不好，而是从“课程实验”这个特定场景出发，MySQL的容错率和上手速度确实更适合独立完成。

2.2 图形化工具：DataGrip、Navicat与命令行怎么选

数据库操作我个人的习惯是：命令行写脚本 + 图形化工具看结果。命令行是基本功，实验报告里要求贴的SQL语句本来就是文本，用命令行执行可以直接复制；图形化工具用来快速查看表结构、检查数据是否插入成功，尤其是刚建完表的时候，看一眼表格会比看结果集更直观。

工具方面，我用过Navicat、DataGrip、DBeaver，还有MySQL自带的Workbench，简单对比一下：

我最终用的是“命令行 + DataGrip”的组合。DataGrip是JetBrains家的产品，对SQL的智能提示做得比较到位，写复杂查询的时候能省很多低级错误。但如果你平时不用JetBrains的IDE，直接用DBeaver就足够了，没必要特意装DataGrip。

还有一点要提醒：不管选哪个工具，安装完第一件事是确认连接信息。主机名、端口、用户名、密码这四个参数，任何一个错了都会连不上。本地连接一般用127.0.0.1或localhost，端口默认3306，用户名习惯用root。如果你在连接时遇到Access denied for user 'root'@'localhost'，先检查密码是不是记错了，大概率不是数据库配置问题。

3. 完整的实操过程：从建库到数据操作，每一步都有据可循

3.1 建库与字符集：为什么必须加上 utf8mb4

拿到任务后，第一步是建库。没有库，所有表都无处安放。我用的建库语句是：

CREATE DATABASE IF NOT EXISTS student_course DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;

这里面两个细节：

• IF NOT EXISTS：如果数据库已存在，不会报错。这个习惯在写脚本的时候特别有用，因为实验往往要重复执行，保证脚本可以“幂等”执行。
• utf8mb4：不是utf8。MySQL的utf8其实是utf8mb3，只能存基本的多语言字符，碰到生僻字或者Emoji会报错或乱码。实验数据里可能不会刻意放Emoji，但“姓名”如果出现生僻字，utf8就有翻车风险，直接用utf8mb4是当前的标准做法。

COLLATE utf8mb4_general_ci是排序规则，_ci表示不区分大小写（case insensitive）。如果以后要做精确匹配且区分大小写，可能需要换成utf8mb4_bin。实验阶段的场景用general_ci就够了。

连接数据库：

USE student_course;

这一步容易漏，漏了的话所有建表语句都会报“No database selected”。如果执行时不想手动切库，也可以在连接数据库时直接指定：

mysql -u root -p student_course

3.2 建表：主键、外键、默认值，一个都不能少

建表语句是实验报告的核心内容，我分三个表展示完整的SQL，并附带关键注释。

学生表：

CREATE TABLE IF NOT EXISTS student ( student_id CHAR(12) NOT NULL COMMENT '学号', name VARCHAR(20) NOT NULL COMMENT '姓名', gender CHAR(1) NOT NULL DEFAULT 'M' COMMENT '性别：M男/F女', birth_date DATE DEFAULT NULL COMMENT '出生日期', class_name VARCHAR(20) DEFAULT NULL COMMENT '班级', enroll_year YEAR DEFAULT NULL COMMENT '入学年份', PRIMARY KEY (student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表';

每个字段的选型在前面已经说过了，这里补充几个执行层面的细节：

• 表名和字段名如果用了系统保留字，比如order、group、desc，必须用反引号（）括起来。但更推荐的做法是直接避开保留字，用class_name而不是class，用select_time而不是time`。
• ENGINE=InnoDB是MySQL默认引擎，也是唯一支持外键约束的引擎。如果你看到有人用ENGINE=MyISAM，那是旧时代的产物，在实验里请无条件使用InnoDB。
• COMMENT写注释不会影响执行，但对实验报告的可读性帮助很大。老师看报告时一眼就能明白你每个字段的意图，印象分能多拿一点。

课程表：

CREATE TABLE IF NOT EXISTS course ( course_id VARCHAR(10) NOT NULL COMMENT '课程编号', course_name VARCHAR(50) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) DEFAULT 0.0 COMMENT '学分，如2.5', teacher VARCHAR(20) DEFAULT NULL COMMENT '授课教师', PRIMARY KEY (course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';

课程编号用VARCHAR(10)而不是CHAR(10)，是因为课程编号不像学号那么规整，有的可能是“CS101”，有的可能是“EE2020-FALL”，长度不固定的语义用VARCHAR更合适。

选课表：

CREATE TABLE IF NOT EXISTS course_selection ( student_id CHAR(12) NOT NULL COMMENT '学号，引用student表', course_id VARCHAR(10) NOT NULL COMMENT '课程编号，引用course表', score DECIMAL(5,2) DEFAULT NULL COMMENT '成绩，0~100', select_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '选课时间', PRIMARY KEY (student_id, course_id), CONSTRAINT fk_sel_student FOREIGN KEY (student_id) REFERENCES student (student_id) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT fk_sel_course FOREIGN KEY (course_id) REFERENCES course (course_id) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课记录表';

这里把前两节铺垫的设计全部落地了：联合主键、两条外键约束、默认时间戳。关于CURRENT_TIMESTAMP，MySQL 8.0 允许在DATETIME字段上直接使用默认值，这是5.7之后才有的能力，如果你用的还是旧版本，可能需要改写成DEFAULT CURRENT_TIMESTAMP配合ON UPDATE CURRENT_TIMESTAMP的组合写法，或者干脆让程序插入时间。

三条建表语句执行完之后，用SHOW TABLES;检查一下，应该能看到三张表都在。再用DESC student;检查一下表结构：

DESC student;

输出结果会列出字段名、类型、是否可空、键信息、默认值和额外属性。对照你的设计草稿逐项检查，发现字段长度不对或者漏了默认值，趁数据还没插入前赶紧改。

3.3 插入数据：顺序有讲究，外键信任是好东西

插入数据是ID使实验脚本报错的重灾区。最核心的一条原则：先插主表，再插从表。学生表和课程表是主表，选课表是从表（因为有外键引用）。如果你先往选课表插数据，而对应学号在学生表里还不存在，数据库会立刻抛外键约束错误，提示类似Cannot add or update a child row: a foreign key constraint fails。

我插的数据是准备了六条学生、四门课程、十组选课记录。三个表的插入操作分别如下：

学生表插入示例：

INSERT INTO student (student_id, name, gender, birth_date, class_name, enroll_year) VALUES ('202301010101', '张伟', 'M', '2005-03-12', '计算机2301', 2023), ('202301010102', '李娜', 'F', '2004-11-25', '计算机2301', 2023), ('202301010201', '王强', 'M', '2005-06-08', '计算机2302', 2023), ('202301010202', '赵敏', 'F', '2004-09-17', '计算机2302', 2023), ('202302010101', '刘洋', 'M', '2004-02-28', '软件2301', 2023), ('202302010102', '陈静', 'F', '2005-01-15', '软件2301', 2023);

一次插入多行放在一条INSERT语句里，比逐行插入效率高，也更容易审查数据是否符合逻辑。注意性别字段我用的'M'和'F'，和建表时的CHAR(1) DEFAULT 'M'是对应的。

课程表插入示例：

INSERT INTO course (course_id, course_name, credit, teacher) VALUES ('CS101', '数据库系统原理', 3.0, '周老师'), ('CS102', '数据结构', 4.0, '吴老师'), ('CS103', '操作系统', 3.5, '郑老师'), ('MA101', '高等数学', 5.0, '孙老师');

在这里插课程表的时候，我一开始犯过一个小错误：把学分写成了3而不是3.0。虽然在DECIMAL(3,1)下效果一样，但为了报告上的规范性，建议显式带一位小数。

选课表插入示例：

INSERT INTO course_selection (student_id, course_id, score, select_time) VALUES ('202301010101', 'CS101', 88.5, '2023-09-01 10:30:00'), ('202301010101', 'CS102', 92.0, '2023-09-01 10:35:00'), ('202301010102', 'CS101', 76.0, '2023-09-02 09:00:00'), ('202301010102', 'MA101', 85.0, '2023-09-02 09:10:00'), ('202301010201', 'CS103', 65.5, '2023-09-03 14:20:00'), ('202301010202', 'CS101', 90.0, '2023-09-04 11:00:00'), ('202302010101', 'CS102', 58.0, '2023-09-05 16:40:00'), ('202302010102', 'CS101', 72.5, '2023-09-06 08:50:00'), ('202302010102', 'CS103', 81.0, '2023-09-06 09:00:00'), ('202302010102', 'MA101', 79.5, '2023-09-06 09:20:00');

插完之后用SELECT * FROM course_selection;看一下结果。如果发现刚才外键约束设置得不对，或者某个course_id写错了，先不急着改数据，先用UPDATE改错，后面还会讲更新的写法。

3.4 查询语言：单表、多表、聚合，一个都别想跑

查询语句是数据库实验拿分的重头戏。很多同学的误区是：查询只要结果对了就行。但实验评分看的是你有没有掌握不同查询类别，所以单表条件查询、多表连接查询、聚合统计查询、排序分页这四个方向都要做齐全。

我根据自己的实验要求，挑了三个典型的查询。

单表条件查询：查所有女学生，按出生日期排序，只显示三个字段。

SELECT student_id, name, birth_date FROM student WHERE gender = 'F' ORDER BY birth_date DESC;

注意ORDER BY的默认顺序是升序ASC，要拿到“年龄最小的在前面”需要用DESC。实验报告里很多人在这里只写ORDER BY birth_date，结果老师一检查发现排序结果和预期不符，扣分还挺冤的。

多表连接查询：查询每个学生的选课情况，显示学号、姓名、课程名、成绩。

SELECT s.student_id, s.name, c.course_name, cs.score FROM student s JOIN course_selection cs ON s.student_id = cs.student_id JOIN course c ON cs.course_id = c.course_id ORDER BY s.student_id, c.course_name;

这里用了别名s、c、cs，整条语句立刻清爽了很多。不要小看别名这个习惯，后续写复杂查询时，没有别名的话ON条件会冗长到怀疑人生。连接类型的细节也值得了解：这个实验用的JOIN是内连接，只返回两边都匹配的行。如果有学生没选课，他的信息不会出现在结果里。如果实验要求列出“所有学生以及他们的选课情况”，那就要用左连接LEFT JOIN，把没选课的学生也带出来，成绩显示为NULL。这个区别老师很有可能在验收时口头提问。

聚合查询：统计每门课程的选课人数和平均成绩。

SELECT c.course_id, c.course_name, COUNT(cs.student_id) AS student_count, AVG(cs.score) AS avg_score FROM course c LEFT JOIN course_selection cs ON c.course_id = cs.course_id GROUP BY c.course_id, c.course_name HAVING student_count > 0 ORDER BY student_count DESC;

这段SQL里有两个值得展开的知识点：

• COUNT(cs.student_id)和COUNT(*)不是一回事。COUNT(*)统计行数，COUNT(列名)只统计该列非NULL的行数。在外连接场景下，如果一个课程没人选，左连接会产生一行但cs.student_id是NULL，COUNT(cs.student_id)会返回0而不是1，这更符合业务语义。
• HAVING和WHERE的分工是：WHERE在分组前过滤行，HAVING在分组后过滤组。你没法用WHERE student_count > 0得到聚合结果，因为student_count是聚合之后才出现的别名。理解这个顺序对调试SQL很有帮助。

3.5 更新与删除：先看影响行数，再交报告

更新和删除操作相对简单，但有几个容易扣分的细节。

更新操作示例：把学号为202301010101的学生的数据库成绩加5分。

UPDATE course_selection SET score = score + 5 WHERE student_id = '202301010101' AND course_id = 'CS101';

这里用了score = score + 5的写法，而不是先查出来再写死具体分数。前者是一个可重复执行的更新逻辑，后者是硬编码，换一条数据就会出问题。实验评分时老师并不关心你是哪种写法，但你自己要有意识地养成写相对表达式的习惯。

删除操作示例：删除学号为202302010101的学生的选课记录。

DELETE FROM course_selection WHERE student_id = '202302010101';

执行之前建议先用同条件的SELECT确认一下要删的范围，养成这个习惯后，不会误删整表。很多新手会直接执行DELETE FROM course_selection;，如果没有WHERE条件，MySQL会删除整个表的记录，而且默认情况下这个操作不会弹窗确认。实验倒是没出事故，但到了工作环境这就是生产事故级的操作。

如果业务上需要“删除学生同时删掉他的选课记录”，外键约束里ON DELETE CASCADE已经做了这件事。你可以先删学生表：

DELETE FROM student WHERE student_id = '202302010101';

然后查选课表，发现对应记录已经被级联删除了。这个行为可以在实验报告里专门写一小段说明，属于加分项。

4. 实操中最容易踩的坑：报错信息与解决思路实录

4.1 中文变问号：字符集与连接字符集的叠加问题

实验数据中文乱码，是最高频的问题。表现形式是查询结果里中文字段显示成?。这个问题的根源分两层：

• 建库、建表时字符集不是utf8mb4，这在前面的设计里已经规避了；
• 客户端连接时的字符集不对。命令行连接时可能默认用了latin1，导致输入的中文以错误编码传入。

解决办法是在连接后设置一下字符集：

SET NAMES utf8mb4;

图形化客户端一般在连接字符串里可以设置characterEncoding=utf-8（Java生态）或直接指定字符集。中文乱码问题排查思路就一句话：客户端用什么编码发送，服务端用什么编码存储，两端不一致必乱。你可以用下面这条语句检查当前连接的字符集配置：

SHOW VARIABLES LIKE 'character_set_%';

重点看character_set_client、character_set_connection、character_set_database这三个变量。

4.2 外键约束导致的“删除失败”和“插入失败”

删除学生表记录时，如果该学生在选课表里有引用，直接删会报错：

DELETE FROM student WHERE student_id = '202301010101';

执行后提示Cannot delete or update a parent row: a foreign key constraint fails。我当时看到这个报错的第一反应是“外键真烦”，但冷静下来就会明白：这正是外键在保护数据完整性。选项有三条：

1. 先删选课表中的对应记录，再删学生；
2. 利用ON DELETE CASCADE，直接删学生自动级联删选课；
3. 如果你想保留选课记录、但又不想留着学生，那说明业务设计本身有问题，实验阶段一般不会这么干。

这种错误本质上不是“怎么绕过”，而是“你的设计策略是什么”。在实验报告里把策略写清楚，比单纯贴一个成功的截图更有说服力。

4.3 重复插入主键：联合主键的正确处理

联合主键的一个特点是：只要(student_id, course_id)组合不重复，插入就允许。我一开始插入选课数据时不小心写了两条完全一样的学号+课程编号记录，第二条插入时直接报了主键冲突：

ERROR 1062 (23000): Duplicate entry '202301010101-CS101' for key 'course_selection.PRIMARY'

这个报错恰恰说明了联合主键的有效性。如果想修改某条记录的关联关系，应该用UPDATE而不是先删后插，比如把某个学生从CS101换成CS102：

UPDATE course_selection SET course_id = 'CS102' WHERE student_id = '202301010101' AND course_id = 'CS101';

注意，如果CS102在课程表中不存在，这条更新同样会触发外键约束错误。所以改数据前先确认目标值一定是合法存在的。

4.4 导入导出脚本：实验报告的防御性做法

做完所有实验操作后，最后一步是把完整的SQL脚本从工具里导出来。很多人是在数据库里手动操作完就截图提交，这不是不好，而是万一老师要现场还原，你就需要一份能一键从头执行的脚本。

两种导出方式：

• 如果用命令行，直接执行mysqldump：

mysqldump -u root -p student_course > backup.sql

• 如果用图形化工具，一般都有“转储SQL文件”按钮。

导出后的脚本里会包含建库语句吗？不一定。MySQL默认的mysqldump不带CREATE DATABASE语句。要完整还原一个库，最好手工在脚本开头加上：

CREATE DATABASE IF NOT EXISTS student_course DEFAULT CHARACTER SET utf8mb4; USE student_course;

然后在后面追加建表语句。这样的一个完整脚本，拿到任何一台装有MySQL的机器上，从头执行到底，就能还原出整份实验的数据和结构。这也是我强烈推荐的提交方式：截图可以有，但脚本才是能验证你真实做过的东西。

5. 实验报告怎么写：把“做完了”变成“做好了”

5.1 报告结构建议

很多学校的实验报告格式是固定的：实验目的、实验环境、实验内容与步骤、实验结果、实验心得。但如果只是按这个模板平铺直叙，容易写成流水账。我推荐在报告里增加一个“设计思路”段落，放在实验步骤之前，用一段话描述：

• 业务场景是什么；
• 实体关系是怎样的；
• 为什么这样设计主键和外键；
• 三张表之间的关联逻辑。

这段描述不需要多长，但能把“我理解这个实验”和“我完成了这个实验”区分开来。老师最怕看到的报告是：一堆SQL代码没有任何解释，虽然能运行，但看不出来你是否理解了为什么这样写。

5.2 每个SQL语句配一个结果截图和一句说明

实验报告的正文，每一段SQL代码后面建议附带执行结果的截图，并在截图上方用一句话说明“这条语句实现了什么功能”。比如：

• “使用内连接查询每个学生的选课情况，结果集包含10行，符合10条选课记录。”
• “使用GROUP BY统计每门课程的选课人数，显示平均成绩最高的课程排序最靠前。”

这种“语句+功能+结果验证”的写法，比单纯贴图强得多。结果行数是对预期的一个验证：比如你插入了6个学生、10条选课记录，那么内连接查询的结果就应该恰好10行。如果查出来12行，说明数据有重复；如果查出来8行，说明有选课记录丢失。这种“预期对比”的思维方式，是数据库实验最值得培养的习惯。

5.3 关于“遇到的错误”写进心得

很多报告的心得部分只会写“通过本次实验，我掌握了基本的SQL语句”。这样写没问题，但太可惜了。我建议把实验过程中真正遇到的报错原样记录下来，然后写清楚是怎么定位和解决的。比如：

“插入选课数据时遇到外键约束失败，排查后发现是选课表先于学生表插入了数据，造成引用不存在的学号。解决办法是先插入学生表，再插入选课表。这个过程中我理解了外键约束的作用原理。”

这种心得才是老师真正想看到的“有效学习证据”，也比你写八句“我深刻认识到……”有用得多。

6. 一点实操体会与扩展建议

做完这个数据库系统实验(1)，我个人的最大体会是：数据库设计这门课，光看书觉得懂了，一上手全是坑。建表看似简单，但主键选什么、外键放哪张表、字段类型用定长还是变长、字符集怎么统一，每个选择背后都有实际代价。这些代价在只有几十条数据的小实验里看不出来，但一旦数据量上到几十万行，一个错误的设计就能让一条查询从毫秒变成秒级。

如果你想在这个实验基础上做点延伸练习，我建议做两件事：

一是给三张表增加索引，再看查询计划。比如在选课表的student_id和course_id上建索引后，用EXPLAIN查看连接查询的执行路径，你会看到type从ALL变成ref，这就是“全表扫描”和“索引查找”的区别。

二是尝试用视图把“每个学生的选课门数和平均成绩”封装起来：

CREATE VIEW student_course_stats AS SELECT s.student_id, s.name, COUNT(cs.course_id) AS selected_count, AVG(cs.score) AS avg_score FROM student s LEFT JOIN course_selection cs ON s.student_id = cs.student_id GROUP BY s.student_id, s.name;

视图的好处在于，后续每次查询“每个学生的统计信息”，直接SELECT * FROM student_course_stats;就行，不需要重复写那一长串连接和聚合。这个思路对应的是开发中的“复用封装”概念，提前接触对你的理解有好处。

实验做到这一步，基础就已经打牢了。后续如果遇到更复杂的实验——比如存储过程、事务、触发器、并发控制——你会发现，它们全部建立在本实验里这些看似朴素的基础上：表设计不合理，后面每一步都在还债；SQL基本功扎实，后面每个实验都是顺水推舟。