简介：这是南华大学《数据库原理》课程实验报告，由大数据技术专业学生完成，面向需要系统学习数据库基础操作与SQL查询的高校学生，尤其适合SQL Server环境下初学者对照练习。资源为doc格式文档，共1个文件，约5.38MB，内容完整清晰。报告覆盖四个实验：认识DBMS、简单SQL查询、高级SQL查询与数据更新，从图形界面建库建表到SQL语句创建数据库、定义主外码与默认值，再到单表筛选、多表连接、分组统计与更新操作，均配有详细代码与执行结果。重点包含学生选课库中学生、课程、选修三表设计与一对多、多对多关系实现，以及按姓名、成绩、系别等条件的查询案例，有助于理解数据完整性和查询优化思路。目前已有376人学习，适合预习复习、完成实验报告或备考使用；文档结构按实验目录组织，便于快速定位知识点，是一份可直接参考的数据库实践资料。

1. 数据库原理实验报告：从交差到交付，差的不只是字数

一份数据库实验报告被退回来，通常不是因为字数不够，而是老师照着你的步骤跑不出预期结果。我见过不少同学把原理写了两三页、SQL 缩在最后一角，验收时连自己建的库都打不开。这个标题背后真正要做的事，不是把实验内容抄成文档，而是用一套可复现的 SQL 脚本，把建库、建表、查询、优化每一步留下证据，再用文字把行为和结果解释清楚。这个方向适合正在补实验记录的在读学生，也适合要带新人走一遍数据落地流程的开发者。你不需要会写复杂的存储过程，但要把环境、表结构、查询逻辑和常见问题这四个维度拉通。

2. 实验前 30 分钟：MySQL 环境与示例表设计决定报告的上限

数据库原理实验最尴尬的情况不是不会写 SQL，而是实验报告写完才发现环境变量没对齐、字符集不对、表结构和理论课讲的外键对不上。我一般会要求补实验的人先花 30 分钟把环境定下来，因为后面所有截图、查询结果、索引分析都建立在这套环境上。环境一旦换，报告里的每一步都要重跑，这是最花时间的返工来源。

2.1 为什么选 MySQL 8.0：对实验报告有三个具体红利

实验课选 MySQL 8.0 是最稳妥的选择。相比 5.7，8.0 默认字符集就是 utf8mb4，中文乱码问题少一大半；自带了窗口函数，实验报告里做“每班成绩排名”“分组 Top N”这类查询时，不用写一堆子查询，展示起来也清爽；还有一个容易被忽略的点，8.0 默认开启了 ONLY_FULL_GROUP_BY，这意味着你在实验里写出的分组查询如果不符合语义，会直接报错，而不是静默返回错误结果。

验证环境是否到位，第一步不是建表，而是先确认版本和字符集基线。打开命令行客户端，执行下面两条语句，把输出结果截图放进报告的“实验环境”一节：

-- 查看 MySQL 版本 SELECT VERSION(); -- 查看服务器端字符集变量 SHOW VARIABLES LIKE 'character_set_server'; -- 查看 SQL 模式，确认 ONLY_FULL_GROUP_BY 是否开启 SHOW VARIABLES LIKE 'sql_mode';

这段操作的价值在于给报告一个可追溯起点。版本和 sql_mode 不确认，后续任何查询行为异常都可能浪费一小时去排查。sql_mode 里如果看不到 ONLY_FULL_GROUP_BY，说明你连的是 5.x 环境或者模式被改过，实验里最好统一以 8.0 默认模式为准。字符集显示不是 utf8mb4 的话，后面的中文字段全部有隐患，先处理环境再看别的。

2.2 最小建库动作：字符集与存储引擎一次设对

很多同学建库就写一句 CREATE DATABASE lab，后面全用默认值。这在实验报告里有风险：默认字符集继承自服务器配置，不同机器跑出来可能不一样，报告截图和实际环境一旦不一致，验收时就会被追问。常见做法是建库时把所有可选项写显式，这样别人复制你的脚本在任何环境上得到的是同一个库。

-- 创建一个课程实验专用的数据库 CREATE DATABASE IF NOT EXISTS lab_school DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci; -- 查看当前库的字符集和排序规则 SHOW CREATE DATABASE lab_school;

新建库时指定 DEFAULT CHARACTER SET 和 DEFAULT COLLATE 两个参数，含义是告诉 MySQL：这个库下面新建的表，如果没单独声明字符集，就统一用 utf8mb4。utf8mb4_0900_ai_ci 是 8.0 默认的排序规则，支持中文按拼音排序，ai 表示口音不敏感，ci 表示大小写不敏感。建完库后用 SHOW CREATE DATABASE 把结果贴进报告，能直观说明你没用默认值糊弄。

存储引擎在实验里选 InnoDB，这是事务和外键约束的前提。MySQL 8.0 里 MyISAM 已经不再推荐，如果你从老教程里复制了 ENGINE=MyISAM，外键是建不上的，后面避坑章节会展开说。实验报告里提一句“所有表均使用 InnoDB 以支持事务与外键约束”，这句话虽然短，但能体现你清楚引擎选型的原因。

2.3 三张示例表：学生-课程-选课模型为什么够用

数据库原理实验的基本盘是关系模型，而学生-课程-选课是教材里最常见的关系模式，它能覆盖主键、外键、复合主键、一对多、多对多五种基础语义。选课表就是学生表和课程表之间的关联表，这个设计理解到位了，后面 JOIN 的实验基本不会跑偏。

-- 学生表：主键为学号 CREATE TABLE student ( student_id CHAR(8) PRIMARY KEY, student_name VARCHAR(20) NOT NULL, class_name VARCHAR(30), enroll_year YEAR ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 课程表：主键为课程号 CREATE TABLE course ( course_id CHAR(6) PRIMARY KEY, course_name VARCHAR(50) NOT NULL, credit TINYINT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 选课表：复合主键，两个外键分别关联学生和课程 CREATE TABLE sc ( student_id CHAR(8), course_id CHAR(6), score DECIMAL(5,1), PRIMARY KEY (student_id, course_id), CONSTRAINT fk_sc_student FOREIGN KEY (student_id) REFERENCES student(student_id) ON DELETE CASCADE, CONSTRAINT fk_sc_course FOREIGN KEY (course_id) REFERENCES course(course_id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

选课表的 PRIMARY KEY 用两个字段做复合主键，表达的语义是“同一名学生选修同一门课只能有一条记录”，这是多对多关系的标准建模。score 用 DECIMAL(5,1) 而不是 FLOAT，因为成绩需要精确到 0.1 分，浮点类型在比较和聚合时会产生误差。外键的 ON DELETE CASCADE 表示删除学生时同步删除选课记录，这个动作在报告里值得写一句“选择级联删除是为了避免孤儿数据”。建表时每个字段都注释清楚为什么这样设计，会比单纯贴一段 DDL 得分高很多。

3. 建库建表与 SQL 查询：把理论课概念写成能跑的代码

实验报告写到查询部分时，常见的翻车点是只贴 SELECT 语句和结果截图，中间不加任何解释。老师看报告时最在意的是你有没有理解自己写的 SQL，而不是结果对不对。所以这一章的写法建议是：每一条查询都拆成“业务需求 → SQL → 执行结果 → 解释”四段，把书写逻辑和执行逻辑分开讲。

3.1 物理设计不是 ER 图：在 CREATE TABLE 里落实主键与外键

有些同学画 ER 图画得很认真，一到建表就简单把字段列出来，主键外键全不建，理由是“数据能查出来就行”。这在实验验收时站不住脚，因为数据库原理实验考查的核心就是约束和关系。如果你的表已经建完但漏了外键，不需要删表重来，用 ALTER TABLE 补上即可：

-- 给选课表补充外键约束（如果建表时漏了） ALTER TABLE sc ADD CONSTRAINT fk_sc_student FOREIGN KEY (student_id) REFERENCES student(student_id) ON DELETE CASCADE;

执行后再用 SHOW CREATE TABLE sc 确认约束状态。补外键时如果报错，最常见的原因是两张表的关联字段类型不一致，比如 student_id 在 student 表是 CHAR(8)，在 sc 表写成了 VARCHAR(8)，MySQL 对类型和长度要求是严格匹配的。这里可以这样理解：外键约束的价值不是让 MySQL 帮你查错，而是让数据在物理层面满足关系完整性。实验报告里把外键的设计意图写清楚，比单纯求“能跑”更有说服力。

3.2 单表查询的书写顺序与执行顺序：报告里必须写清两个逻辑

这是实验报告里最能体现基本功的部分。很多同学能写对 SQL，但被问“WHERE 和 HAVING 有什么区别”“能不能用别名在 WHERE 里过滤”就卡住。建议在报告里专门用一小节写清楚：SQL 的书写顺序是 SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，而执行顺序是从 FROM 开始，再到 WHERE、GROUP BY、HAVING，最后到 SELECT 和 ORDER BY。理解这两个顺序，写查询时就不会心智混乱。

下面这个例子是“统计 2023 级每个班级的选课人数和平均成绩，筛选选课人数大于等于 2 的班级，按平均成绩降序取前 3”：

SELECT s.class_name, COUNT(*) AS student_cnt, AVG(sc.score) AS avg_score FROM student s JOIN sc ON s.student_id = sc.student_id WHERE s.enroll_year = 2023 GROUP BY s.class_name HAVING COUNT(*) >= 2 ORDER BY avg_score DESC LIMIT 3;

WHERE 在分组之前过滤原始行，所以 enroll_year = 2023 的条件必须放在 WHERE 里；HAVING 在分组之后过滤聚合结果，所以选课人数大于等于 2 必须放在 HAVING 里。如果你把 enroll_year 的条件写进 HAVING，查询也能跑，但语义就错了。AVG(sc.score) 在 MySQL 中会自动忽略 NULL，但如果字段类型本身允许 NULL，最好在报告里说明这一点，避免让人误以为空值被算成了 0。

3.3 多表 JOIN：关联条件、别名与三种连接的选用边界

JOIN 相关的实验翻车，十有八九是没加别名导致字段歧义。student、course、sc 三张表里如果都有 name 或 id 字段，SELECT 时不带表前缀就直接报错。我给学生改实验时经常说：不管查询里涉及几张表，一律给表起别名，这不是代码风格，是避免出错的操作习惯。

以“列出每门课程的选课人数，包括从未被选过的课程”为例：

SELECT c.course_id, c.course_name, COUNT(s.student_id) AS selected_cnt FROM course c LEFT JOIN sc ON c.course_id = sc.course_id LEFT JOIN student s ON sc.student_id = s.student_id GROUP BY c.course_id, c.course_name ORDER BY selected_cnt DESC;

这里用了两次 LEFT JOIN，目的是保留 course 表中的未被选课程，也就是右表没有匹配记录时，LEFT JOIN 仍然返回左表的一行。COUNT(s.student_id) 与 COUNT() 是有区别的：COUNT(s.student_id) 只统计非 NULL 的学号，未选课课程的选课人数就是 0；而 COUNT() 会把课程记录本身也算一行，结果变成 1，这是实验报告里极容易写错又极容易被追问的点。

INNER JOIN、LEFT JOIN、RIGHT JOIN 的选择依据只有一个：查询结果要保留哪一边的未匹配行。这个判断标准如果在报告里写明白，后面任何 JOIN 场景都不会晕。

4. 索引、事务与视图：三个更容易拉开分数差距的实验点

到了索引和事务，实验报告的区分度就出来了。前面建表和查询大家写出来都差不多，但索引靠 EXPLAIN 证明、事务靠隔离级别分析、视图靠使用动机，这三块做扎实了，报告基本能到优秀档。

4.1 索引：用 EXPLAIN 证明索引生效，而不是只贴 CREATE INDEX

索引实验最大的误区，是建完索引只截个 SHOW INDEX 的结果就完事。真正有效的做法是给出索引前后的执行计划对比，也就是 EXPLAIN 输出。比如选课表经常按 student_id 查，那就给这个字段建普通索引：

-- 给选课表的学号列创建普通索引 CREATE INDEX idx_sc_student ON sc(student_id); -- 查看查询是否走索引 EXPLAIN SELECT * FROM sc WHERE student_id = 'S001';

EXPLAIN 的结果里主要看三列：type 是访问类型，出现 ref 或 range 说明索引生效，ALL 表示全表扫描；key 显示实际用到的索引名；rows 是预估扫描行数，加索引后这个数字通常明显下降。报告里放一张加索引前后 EXPLAIN 的对比截图，比任何文字都直观。

索引不是建得越多越好。对性别、状态这种只有两个取值的字段建索引，type 大概率还是 ALL，因为选择度太低，优化器认为全表扫更快。课堂常常把“索引失效”讲得很玄学，但实验里最常遇见的就两类：对索引列用了函数或运算，比如 YEAR(enroll_year);或者 LIKE 以通配符开头，比如 LIKE '%C001%'。报告里写一句“索引对前导模糊匹配无效”，就能证明你踩过坑且知道原因。

4.2 事务：把隔离级别和并发异常做成一张对照表

事务实验的标准案例是账户转账。代码很短，但每一步都对应教材里的 ACID 属性，值得拆开来讲：

START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE user_id = 'A'; UPDATE account SET balance = balance + 100 WHERE user_id = 'B'; COMMIT;

两条 UPDATE 必须放在同一个事务里执行的原因，是避免第一条成功、第二条失败时出现扣款不增加的中间状态。如果在第二条 UPDATE 之后、COMMIT 之前执行 ROLLBACK，两条修改都会回滚。我一般建议实验报告里把这个场景写成三份：正常提交的截图、中途回滚的截图、以及一个表来说明隔离级别与并发异常的关系。

MySQL 8.0 默认隔离级别是 REPEATABLE READ，可以用 SELECT @@transaction_isolation; 查出来并截图放在报告里。InnoDB 在 REPEATABLE READ 下通过间隙锁基本避免了幻读，这一点和 SQL 标准不完全一致，属于加分项，能写出来说明你理解引擎细节而不只是背标准。

4.3 视图：把复杂 JOIN 封装成一个逻辑表

视图实验的核心不是 CREATE VIEW 语法，而是理解它解决什么问题。一个多次使用的三表关联查询，每次写都容易漏条件，封装成视图后，查询就变成针对一个虚拟表的单表查询：

-- 创建学生选课成绩视图 CREATE VIEW v_student_course AS SELECT s.student_name, c.course_name, sc.score FROM sc JOIN student s ON sc.student_id = s.student_id JOIN course c ON sc.course_id = c.course_id; -- 基于视图查询 SELECT * FROM v_student_course WHERE score >= 60;

视图不是物化表，MySQL 里它只是一条保存起来的 SELECT 语句，每次查询视图都会重新执行底层 SQL。这个点实验报告里建议专门提一句：视图不额外占用存储空间，但也不能像表一样单独建索引。视图的另一个实际价值是权限控制：你只给应用账号开放视图，而不开放底层表，这样用户看不到字段之外的敏感列。把这两个用途写清楚，视图部分的报告就不用愁了。

5. 数据库实验避坑指南：5 个常见翻车现场与排查路径

实验报告写好之后返工，基本都发生在环境或细节上。下面是补实验时最常遇到的五个坑，按“现象、原因、解决”写清楚，你可以对照自己报告逐个排查。

5.1 中文乱码：字符集三处没对齐

现象：插入数据时中文显示成？？，或导出 SQL 重新导入后发现中文内容变成乱码。 原因：客户端连接字符集、数据库默认字符集、建表字符集其中有一个不是 utf8mb4。MySQL 8.0 服务端默认已经是 utf8mb4，但命令行客户端或图形工具连接的字符集可能沿用系统旧设置。 解决：建库时显式写 DEFAULT CHARACTER SET utf8mb4，连接后执行 SET NAMES utf8mb4，再用 SHOW VARIABLES LIKE 'character_set%'; 把所有字符集变量截图留证。如果已经导入乱码数据，把表 DROP 掉，统一字符集后重新导入，不要尝试 UPDATE 修复，那只会把数据改得更乱。

5.2 外键建立失败：报错 1215 和 1822

现象：执行 ALTER TABLE 或 CREATE TABLE 添加外键时，报错 Can't create table 或 Cannot add foreign key constraint。 原因：最常见三种——表是 MyISAM 引擎不支持外键；外键列与被引用列类型或长度不一致；被引用列不是主键或唯一索引。 解决：统一把表改成 ENGINE=InnoDB，检查两个字段类型完全一致，比如 CHAR(8) 对 CHAR(8)，不要让一边是 VARCHAR(8)。被引用列直接用主键是最省事的做法。报错信息里有时会提示 Missing index for constraint，意思是被引用列上没有索引，此时给列加唯一索引即可。

5.3 字段名撞了保留字：反引号不是可有可无

现象：建表 SQL 语法检查没问题，执行时报语法错误，提示位置就在某个字段名附近。 原因：字段名用了 desc、order、level、group、rank 这类保留字或内置函数名。写代码时顺手起的名，到 SQL 解析器那里就被拦下来了。 解决：设计阶段避开保留字，这是最推荐的做法。如果表已经建好，用反引号把字段包起来，例如descVARCHAR(20)。MySQL 的反引号是唯一标识符引用符，能用但不建议大量使用，因为换到其他数据库就要改写法。

5.4 聚合查询数量对不上：COUNT 和 GROUP BY 的语义错位

现象：统计“每门课选课人数”时，结果要么多出来几条，要么比预期少，和明细数据对不上。 原因：把多张表 JOIN 之后直接 COUNT() 计数，JOIN 会让重复行被一起统计；或者 GROUP BY 的字段没有包含 SELECT 中的全部非聚合字段，在 ONLY_FULL_GROUP_BY 开启时直接报错。 解决：先明确分组粒度，统计选课人数时在主表上做聚合，再关联课程表；如果 JOIN 造成重复，就先用子查询把聚合结果算出来，再连表取课程名称。报告里用 COUNT(s.student_id) 和 COUNT() 各写一次并说明差异，反而能体现你查过资料。

5.5 导入 SQL 文件跑一半报错：分隔符与主键冲突

现象：从图形工具导出的 SQL 文件，在命令行执行到一半报错，经常是某条 INSERT 提示主键重复。 原因：导出脚本里带有 DELIMITER 命令，用于切换存储过程或触发器的分隔符，直接在 MySQL 命令行逐条执行没问题，但使用某些图形工具导入时脚本解析到一半会卡住；另一个原因是脚本重复执行，第一次已经插入了数据，第二次跑 INSERT 自然主键冲突。 解决：重新导入前先 DROP TABLE 或用 TRUNCATE 清空数据；在命令行里用 source 方式执行脚本，而不是把整个文件内容粘进客户端。每次导入后做一次 COUNT(*) 校验，确认行数和你导出前一致，这个习惯能省掉大量返工。

6. 验收前通读：让报告经得起一次追问的四个自检习惯

实验报告提交前，我会花十几分钟做四个检查，基本能拦住绝大多数返工。第一个检查是重跑：把报告里的每一条 SQL 按顺序重新执行一遍，确认截图和当前环境一致。很多报告的问题出在改了表结构忘了更新查询截图，这一跑就露馅。第二个检查是边界：随机抽一条查询问自己，WHERE 和 HAVING 为什么这样分配，COUNT(*) 和 COUNT(s.student_id) 结果会不会不同，答不出来就回到第 3 章补解释。第三个检查是索引证据：打开 EXPLAIN，确认报告的每一张索引图都对应一条能说明问题的执行计划，而不是空放一张图。第四个检查是数据版本：把报告里提到的一组样例数据单独存成 SQL 文件，保证任何时刻都能重新生成同样结果，避免答辩时只能指着一张截图干讲。

我有一次补实验时，把旧版本的建表语句复制进报告，结果后文的查询截图用的却是新表结构，导师只看了一眼就问“你建表语句里没有这个字段，这个结果怎么来的”。当场重新核对才发现，截图和脚本差了整整一个字段。那之后养成的习惯是：所有实验提交前必须完整跑一遍脚本，宁可多花十分钟，不再因为一张对不上的截图去解释。希望帮到你，也祝这份报告一次过。

本文还有配套的精品资源，点击获取