简介这是南华大学《数据库原理》课程实验报告由大数据技术专业学生完成面向需要系统学习数据库基础操作与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.78.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 已经不再推荐如果你从老教程里复制了 ENGINEMyISAM外键是建不上的后面避坑章节会展开说。实验报告里提一句“所有表均使用 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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 课程表主键为课程号 CREATE TABLE course ( course_id CHAR(6) PRIMARY KEY, course_name VARCHAR(50) NOT NULL, credit TINYINT ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 选课表复合主键两个外键分别关联学生和课程 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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;选课表的 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两条修改都会回滚。我一般建议实验报告里把这个场景写成三份正常提交的截图、中途回滚的截图、以及一个表来说明隔离级别与并发异常的关系。隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不可能可能可能REPEATABLE READ不可能不可能可能InnoDB 下基本规避SERIALIZABLE不可能不可能不可能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 添加外键时报错 Cant create table 或 Cannot add foreign key constraint。 原因最常见三种——表是 MyISAM 引擎不支持外键外键列与被引用列类型或长度不一致被引用列不是主键或唯一索引。 解决统一把表改成 ENGINEInnoDB检查两个字段类型完全一致比如 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 文件保证任何时刻都能重新生成同样结果避免答辩时只能指着一张截图干讲。我有一次补实验时把旧版本的建表语句复制进报告结果后文的查询截图用的却是新表结构导师只看了一眼就问“你建表语句里没有这个字段这个结果怎么来的”。当场重新核对才发现截图和脚本差了整整一个字段。那之后养成的习惯是所有实验提交前必须完整跑一遍脚本宁可多花十分钟不再因为一张对不上的截图去解释。希望帮到你也祝这份报告一次过。本文还有配套的精品资源点击获取