简介：《zzu数据库实验报告书》是一份面向计算机科学与技术、软件工程专业学生的数据库系统原理课程实验合集，围绕openGauss数据库环境，依次覆盖认识DBMS、创建数据库表与索引、交互式SQL语句、创建视图、完整性与安全性控制、事务与并发控制、数据库备份与恢复，以及使用JDBC连接数据库等九大实验模块，可帮助学习者巩固课堂理论、建立从数据建模到实际操作的完整认知。资源包共1个文件，为docx格式的实验报告正文，整体大小3.23MB，报告结构清晰、环节完整，包含实验目的、操作过程、问题更正、结果分析与实验截图说明。目前已有1521人学习下载，适合正在修读数据库原理课程、需要撰写实验报告或准备复习的在校生。对于希望掌握openGauss常用命令、SQL开发及数据库安全、并发处理等核心技能的学习者，这份报告可提供直接的实践参照与排版范本。

1. zzu数据库实验报告书到底交付什么：先搞清楚评分逻辑再动手

如果把某高校代号课程里的数据库实验报告书当成一次普通作业来赶，很容易在提交前夜翻车。这门课的交付物并不是SQL代码，而是那份报告书。老师主要通过它判断你有没有真的在数据库上做过实验，能不能把一份代码讲清楚。很多同学花大量时间把SQL跑通，报告书却只有截图加源代码，结果分很低；也有人代码写得一般，但把设计过程、验证数据和踩坑记录写清楚了，反而拿到了不错的分数。这篇笔记会把一份能拿出手的实验报告书拆开讲：环境怎么交代、建库脚本怎么落盘、正文按什么结构组织、查询索引事务这几类必做实验怎么做成可复现结果，以及最容易翻车的细节和提交前的自查方法。

2. 报告书先拼环境：数据库选型、连接参数与建库脚本约定

2.1 为什么报告书第一页要写清环境：选型与版本约定

数据库实验和普通编程实验不一样，结果高度依赖运行环境。同一个SQL语句，在不同版本上跑出来的排序可能不同，对窗口函数和公共表表达式的支持也完全不同。报告书第一页写清环境，是为了让读报告的人能复现你的操作；也是给自己留后路，期末复查时能还原现场，不用靠记忆填参数。如果第一页缺了版本信息，老师想验证附录里的脚本时，第一步就会卡住。

选型方面，常见做法是跟着课程指定的数据库系统走；如果课程没有硬性规定，我一般会用MySQL 8.x作为默认选项。原因是大多数同学对它最熟悉，安装包小，命令行工具齐全，遇到问题容易搜到答案；少数涉及对象关系特性的实验会切换到PostgreSQL系。不推荐在一门课中途换库，因为导出导入格式有差异，报告书前后会自相矛盾，连接参数的写法也要全部重来。

报告书第一页的环境信息表可以按下面这个模板写，提交前逐项核对一次。

2.2 最小建库脚本：把DDL和初始化数据落盘到init.sql

报告书里最容易被忽略的一步，是只把表和 SQL 贴在文档里，却不肯保留一份独立可执行的建库脚本。实际上，指导老师复查时最常做的事，就是拿到附录里的脚本跑一遍。如果脚本缺了依赖关系，或者建表语句和正文截图不一致，一下就露馅了。所以项目一开始就要建立 db 目录，把建库脚本命名为 init.sql 保存下来，报告书附录里附上同名文件内容。

先创建目录和脚本文件：

mkdir -p db && cd db touch init.sql

然后在这个文件里写入建库建表和初始数据。下面是一个最小示例，对应学生选课场景：

-- 数据库课程实验报告书的初始化脚本 init.sql -- 目标库：course_lab，字符集 utf8mb4 DROP DATABASE IF EXISTS course_lab; CREATE DATABASE course_lab DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE course_lab; -- 学生表：学号为主键，年龄允许 NULL 以演示约束 CREATE TABLE student ( id INT PRIMARY KEY, name VARCHAR(50) NOT NULL, age INT NULL, class_name VARCHAR(50) DEFAULT '未分班' ) ENGINE=InnoDB; -- 课程表：课程号固定 8 位字符 CREATE TABLE course ( course_id CHAR(8) PRIMARY KEY, course_name VARCHAR(100) NOT NULL, credit DECIMAL(3,1) DEFAULT 1.0 ) ENGINE=InnoDB; -- 选课表：联合主键，外键引用 student 和 course CREATE TABLE enrollment ( student_id INT NOT NULL, course_id CHAR(8) NOT NULL, score DECIMAL(5,2) NULL, PRIMARY KEY (student_id, course_id), CONSTRAINT fk_enroll_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_enroll_course FOREIGN KEY (course_id) REFERENCES course(course_id) ) ENGINE=InnoDB; -- 先插入父表，再插入子表，避免外键校验失败 INSERT INTO student (id, name, age, class_name) VALUES (1, 'A同学', 20, '计科1班'), (2, 'B同学', 19, '计科1班'), (3, 'C同学', NULL, '计科2班'); INSERT INTO course (course_id, course_name, credit) VALUES ('CS101', '数据库原理', 3.0), ('CS102', '数据结构', 3.5); INSERT INTO enrollment (student_id, course_id, score) VALUES (1, 'CS101', 88.5), (2, 'CS101', 76.0), (3, 'CS102', NULL);

这段脚本有两个关键设计：一是字符集统一写在 CREATE DATABASE 后面，后续所有表都继承库级配置，避免单表单独设置造成不一致；二是插入顺序严格按照父表到子表，先把 student 和 course 的数据准备好，再插 enrollment，这样外键约束不会中途报错。报告书正文里，建议在附录前加一句说明，标明测试通过的环境版本，例如“该脚本在 MySQL 8.x，utf8mb4 环境下验证通过”。

2.3 连接参数的三个必调项：字符集、时区、自动提交

很多实验报告里的异常现象，最后都排查到连接参数上。比如用图形工具连库时中文正常，换成命令行执行就乱码；比如事务实验里明明执行了提交，另一个窗口却读不到修改。这些往往不是数据库本身的问题，而是连接设置和库端设置不一致。写报告书之前，先统一三件事：连接字符集、时区、自动提交。

下面的 Python 连接示例可以直接放到实验环境里验证：

import pymysql conn = pymysql.connect( host="127.0.0.1", port=3306, user="root", password="your_password", database="course_lab", charset="utf8mb4", # 与建库字符集保持一致 autocommit=False, # 关闭自动提交，事务实验才能控制 init_command="SET time_zone = '+08:00'" # 统一时区，避免日期函数结果漂移 )

这里的 charset 必须和 init.sql 里的库级字符集一致，否则查询结果里的中文在 Python 侧会显示乱码。autocommit 设成 False 是为了让事务控制在应用层显式提交或回滚，否则 UPDATE 语句一执行就生效，后面再做 ROLLBACK 也救不回来，事务实验就没法演示了。time_zone 这一项容易被忽略，一旦系统默认时区不是东八区，NOW() 和日期格式化函数的结果会差出好几个小时，两个终端分别连接时更难以对齐现象。

报告书里怎么处理这三项？不需要贴一大段连接代码，而是在每个涉及事务和日期函数的实验开头，用一行文字说明“本实验连接参数为 utf8mb4、autocommit=False、东八区”。这样老师复查时即使遇到怪现象，也知道是环境差异造成的，不是实验逻辑本身错了。

3. 报告书正文结构：按题目、设计、过程、验证四段组织

3.1 四段式结构下每类实验的写法差异

数据库实验报告书最常见的通病，是把所有实验题的代码按顺序贴一遍，每题只有题目、SQL、截图，没有设计说明，也没有验证过程。这种文档看起来完整，实际上既无法证明结果是你跑出来的，也没法让读者理解为什么这样写。比较好的做法是每道题统一按四段组织：题目描述、关系设计与思路、执行过程、验证结果与分析。不同实验类型在这四段里的侧重点不太一样。

以查询实验为例，题目描述只占两三行，核心要写清楚“为什么用 JOIN 而不是 WHERE 连接”，以及“这条查询在数据量多大时跑得动”。事务实验则相反，题目本身很简单，重点是过程中两个终端各自看到了什么，提交前和提交后另一个连接能否读到变化。这些内容不能靠模板生成，必须对着自己实际跑出来的结果写。

3.2 从实验题目到E-R图再到关系模式：先画图再写SQL

实验报告书里最难的一部分，不是把 SQL 跑通，而是把“题目描述”转化成 E-R 图，再转化成关系模式，最后才落到建表语句。很多同学跳过中间两步，直接凭感觉写 CREATE TABLE，结果一张表的主键和外键都定了，却没有覆盖题意里的某个联系，后面再改表结构成本很高。

我一般会在报告书里放一个表格形式的实体属性清单，不强制画图工具，但一定要把实体、属性、主键写清楚。比如“学生选课”这个场景可以整理成下面这样：

这个表格写完之后，关系模式自然就出来了。学生关系模式：学生(学号, 姓名, 年龄, 班级)，主键学号。课程关系模式：课程(课程号, 课程名, 学分)，主键课程号。选课关系模式：选课(学号, 课程号, 成绩)，主键为学号和课程号的组合，同时学号引用学生表，课程号引用课程表。把这三种表示方式按顺序放进报告书，阅卷老师能一眼看出设计过程是完整的，而不是从某个模板里复制来的。

如果题目涉及多对多联系，比如一个学生选多门课、一门课被多个学生选，就必须加中间表。这时候把 E-R 图转关系模式的规则写上：多对多联系单独成为一张表，两端实体的主键进入联系表做外键，联系本身的属性也放在联系表里。这样实验 1 的建库部分就不再是简单罗列 DDL，而是有清晰推导过程的设计文档。

3.3 验证数据这样构造：边界数据比随机数据更说明问题

报告书里“验证”这一段，是最能拉开分差的地方。只贴 SELECT 结果集，只能证明这条 SQL 能跑；但设计一组边界数据，证明某个约束在异常情况下也同样生效，才说明你理解了这个约束的作用。我会在每张表里额外准备几条“故意让它失败”的数据，用来验证 NOT NULL、主键冲突、外键悬空等规则。

下面这组边界插入语句可以直接放到实验报告书的验证部分：

-- 验证 name 字段 NOT NULL 约束：预期失败 INSERT INTO student (id, name, age, class_name) VALUES (4, NULL, 21, '计科1班'); -- 验证主键唯一性：预期失败，因为学号 1 已存在 INSERT INTO student (id, name, age, class_name) VALUES (1, 'D同学', 20, '计科1班'); -- 验证外键约束：预期失败，因为学号 99 在 student 表中不存在 INSERT INTO enrollment (student_id, course_id, score) VALUES (99, 'CS101', 60.0);

第一条数据在字段约束层面触发失败，第二条在主键索引层面触发失败，第三条在外键校验层面触发失败。报告书里不能只写“运行报错”，应该把每条语句对应的错误码或错误提示写出来，比如“Duplicate entry '1' for key 'student.PRIMARY'”，然后补一句“该错误符合预期，证明主键唯一性约束生效”。这种写法让验证部分变成了可复现的检查清单，而不是单纯的截图合集。

构造边界数据还有一个注意点：不要只构造失败数据，成功数据也要覆盖业务边界。比如选课成绩允许 NULL，就要有一条成绩为 NULL 的选课记录，用来验证后续统计 AVG 时 NULL 不会被计入。这一类数据，正是查询实验里结果和预期之间最容易出现偏差的地方，提前在实验 1 的初始化脚本里埋好，后面实验会省很多事。

4. 核心实验做扎实：查询、索引、事务三类必做内容的可复现写法

4.1 多表连接与分组聚合：执行顺序决定SQL怎么写

数据库课程实验里，查询类实验通常绕不开多表连接、分组聚合和排序。很多新手在这里翻车，不是因为语法记不住，而是没搞清楚 SQL 各子句的执行顺序，结果把聚合函数写进 WHERE，或者对别名做过滤而报错。一条 SQL 的完整执行顺序是：先取数据源，再过滤数据源，再分组，再过滤分组结果，接着排序，最后投影。这个顺序直接决定了写法。

以学生选课为例，如果题目要求统计每门课程的选课人数和平均分，同时只看学分不低于 2.0 的课程，并且只需要有选课记录的课程，标准写法如下：

SELECT c.course_name, COUNT(e.student_id) AS enroll_count, AVG(e.score) AS avg_score FROM course c LEFT JOIN enrollment e ON c.course_id = e.course_id WHERE c.credit >= 2.0 GROUP BY c.course_id, c.course_name HAVING enroll_count >= 1 ORDER BY enroll_count DESC;

这段代码里有几个容易写错的地方。WHERE 发生在分组之前，所以它只能过滤 course 表的原始字段 credit，不能写 enroll_count；HAVING 发生在分组之后，所以它可以引用 COUNT 的别名 enroll_count；GROUP BY 后面不能只写 c.course_id，必须把 c.course_name 也带上，否则某些窗口模式下会因为 ONLY_FULL_GROUP_BY 直接报错。报告书里遇到这类查询，我建议把执行顺序写进分析段，比单纯贴结果集更能说明原理理解程度。

如果老师进一步要求分析性能，可以在查询前加 EXPLAIN，把执行计划放进报告书。报告书里只需要贴出 type、key、rows 这三列，并用自己的话解释：这条查询走了哪个索引，大致扫了多少行，还有没有全表扫描风险。这样比贴一大张执行计划截图更清楚。

4.2 索引实验的必调参数：EXPLAIN、覆盖索引、复合索引字段顺序

索引类实验在报告书里常常变成走过场。建一个索引，跑一遍，结果变快，结束。但实际上索引实验要写清楚三个问题：为什么建这个字段、怎么验证生效、复合索引的字段顺序有什么讲究。先看一个带索引的对比场景。课程实验里，如果频繁按 student_id 查选课记录，初始状态可能没有索引，EXPLAIN 显示全表扫描；建立一个复合索引之后，扫描行数明显变少。

-- 在选课表上建立复合索引 ALTER TABLE enrollment ADD INDEX idx_stu_course (student_id, course_id); -- 查看执行计划 EXPLAIN SELECT student_id, course_id, score FROM enrollment WHERE student_id = 1;

复合索引 idx_stu_course 的字段顺序是 student_id 在前，course_id 在后。这个顺序的选择依据是最左前缀规则：查询条件里只要包含 student_id，索引就能命中；如果查询只带 course_id，这个索引就帮不上忙。报告书里要用实验数据说话，做法是分别对“有索引”和“无索引”两种状态执行 EXPLAIN，然后把 type 和 rows 放在对比表格里。

还要注意一个细节：不是所有查询都需要索引。如果表里只有三行数据，全表扫描和索引查找的差异肉眼几乎看不出来，反而因为索引维护增加了写入成本。报告书里如果写了“加索引后变快了”，要确认数据量是否足够支撑这个结论，否则会被阅卷老师质疑实验设计不严谨。覆盖索引也是一个可以提的点：查询列恰好都在索引里时，回表次数为 0，可以通过 Extra 列里的 Using index 来验证。建议把这一项写进进阶分析，分值会明显不一样。

4.3 事务实验：隔离级别、提交与回滚的验证脚本

事务实验是报告书里最难用截图证明真实性的实验，因为它的核心现象是“另一个连接看不到未提交的数据”。只贴一条事务代码，然后说“成功了”，等于没有做实验。正确做法是开两个终端，一个终端执行更新但不提交，另一个终端在同一个隔离级别下查询，观察结果是否可见；然后对比提交之后的结果。把这个过程完整描述出来，才是真正可复现的事务验证。

下面这段 Python 脚本可以用来模拟事务控制：

import pymysql # 连接A：事务中执行更新，但不提交 conn_a = pymysql.connect(host="127.0.0.1", port=3306, user="root", password="your_password", database="course_lab", charset="utf8mb4", autocommit=False) cur_a = conn_a.cursor() cur_a.execute("SET TRANSACTION ISOLATION LEVEL REPEATABLE READ") cur_a.execute("UPDATE enrollment SET score = 90 WHERE student_id = 1 AND course_id = 'CS101'") # 在连接A内查询，能看到自己更新的数据 cur_a.execute("SELECT score FROM enrollment WHERE student_id = 1 AND course_id = 'CS101'") print("连接A事务内查询:", cur_a.fetchall()) # 连接B（新建连接）此时做同样的查询 conn_b = pymysql.connect(host="127.0.0.1", port=3306, user="root", password="your_password", database="course_lab", charset="utf8mb4", autocommit=False) cur_b = conn_b.cursor() cur_b.execute("SELECT score FROM enrollment WHERE student_id = 1 AND course_id = 'CS101'") print("连接B在A提交前查询:", cur_b.fetchall()) # 期望看到原来的分数 conn_a.rollback() # 回滚连接A的更新 conn_a.close() conn_b.close()

这段代码的关键在于连接A执行了 UPDATE 但回滚，连接B在同一个 REPEATABLE READ 隔离级别下，查询结果应该保持原值。报告中要写清楚这个现象，并解释回滚让更新失效了，所以看不到修改。如果把 autocommit 设成 True，连接A执行完 UPDATE 的瞬间事务就已经提交，连接B立刻就能查到新值，那么整个实验就失去对比意义了。这就是为什么前面强调连接参数里必须显式控制 autocommit。

另一个值得写的点是隔离级别之间的差异。把 SET TRANSACTION ISOLATION LEVEL 改成 READ COMMITTED 或者 READ UNCOMMITTED，再跑同一段代码，观察到的结果会不一样。如果课程没有要求深挖，可以不展开，但至少要把当前用的隔离级别写进报告书，否则老师无法判断你的现象描述是基于哪种隔离级别得出的。

5. 避坑：数据库实验报告书最常见的五个翻车点

5.1 截图里的结果和提交的.sql跑出不一样：先定稿再截图

现象：老师复查时手动执行附录里的 init.sql，发现建表字段和正文截图对不上，或者查询结果少一行，直接判定报告书抄袭或敷衍。 原因：写报告时先跑了旧版本代码，后面又改了 SQL，却忘了重新截图，图里是旧结果，附录里已经是新代码。 解决：规定动作是“先定稿代码，再生成报告”。所有实验代码先在 db 目录里跑通并确认最终版，然后按最终版重新截图，保证报告书里每一处结果都来源于当前提交的脚本。提交前一天再抽查一条查询，对着附录代码手动执行一次，如果结果不一致，重截该处截图。

5.2 中文乱码和字符集不统一：根因在四层不一致

现象：报告书附录里的建库脚本在课堂上执行时中文全部变成问号，结果集里的中文也是乱码。 原因：建库时用的是 utf8mb4，但 sql 文件本身被某个编辑器保存成了 GBK，或者命令行客户端连接的默认字符集不是 utf8mb4。要么是库端不一致，要么是客户端连接端不一致，四层里任何一层出问题都会乱码。 解决：统一用 utf8mb4 一条路走到底。建库参数写 utf8mb4，连接参数写 charset=utf8mb4，文件保存编码确认是 UTF-8，命令行执行前执行一句 SET NAMES utf8mb4。报告书里可以在环境表加一行“字符集规范”，写明统一策略，这样即使真的乱码也容易排查。

5.3 外键插入顺序引发的假报错：从父表到子表

现象：初始化数据执行到一半，插入 enrollment 表时报外键约束错误，学生以为脚本写错了。 原因：不是 SQL 拼写错，而是插入顺序违反外键依赖。先插了子表，但父表里还没有对应记录。 解决：所有 INSERT 按父表到子表的顺序执行。init.sql 里先插 student 和 course，再插 enrollment。如果实验数据里确实需要先处理子表，可以临时把外键检查关掉，执行完数据插入后再恢复，命令是 SET FOREIGN_KEY_CHECKS=0 和 SET FOREIGN_KEY_CHECKS=1。报告书里出现这类操作时，要把开关语句写进脚本，不能只在心里恢复。

5.4 多题结果混在一起：题号注释加结果标题

现象：报告书正文连续贴了多条 SQL 和多个结果集，但看不出来哪条对应哪个实验题。 原因：代码直接复制，没有添加题目标注，结果集也没有命名，读者只能靠猜。 解决：每条 SQL 前用注释写清题号，比如 -- 实验2.1：查询学分大于3的课程；结果集前加一行加粗标题“实验2.1 执行结果”。这样整份报告书从第一章到最后一章，段落之间边界清晰，老师复查时对着题号就能快速定位。另外一个细节是多条查询共用一张结果图时容易漏行，建议每条查询单独截结果集，不拼接。

5.5 换机器导入报Unknown database：先连库再source

现象：把 init.sql 拷贝到另一台机器上执行，报错 ERROR 1049: Unknown database 'course_lab'，但脚本开头明明写了 CREATE DATABASE。 原因：客户端工具或命令行在执行脚本前就已经指定连接到一个不存在的数据库，然后脚本中的 USE course_lab 找不到目标库。 解决：在真正的命令行环境里，先不带库名登录，登录后再执行 source 命令；或者在执行时使用 mysql -u root -p < init.sql，而不是 mysql -u root -p course_lab < init.sql。如果在图形工具里执行，也要先确认连接对象里没有指定具体的 database。报告书附录里如果包含建库脚本，建议在说明文字中加一句“执行时先登录再 source”，这个提示能避免复查时被环境问题卡住。

6. 报告书收尾：用评分点自查一遍再提交

6.1 五分钟自查清单：照着这份表过一遍

提交前最有效的动作，是把自己想象成阅卷老师，手里只有这份报告书，从头到尾读一遍，看能不能完全复现。我会默认每份报告书都会被抽查执行，所以自查清单里每一项都很具体。

这些检查点做下来不会超过五分钟，但能拦住八成以上的低级失误。尤其是“随机挑一条SQL执行”这一条，截图和代码不一致的问题，只有真正跑一遍才能暴露。

6.2 把“失败记录”写成差异化素材：避免千篇一律

报告书里真正体现个人痕迹的，不是大段正确的代码，而是你遇到的问题和解决的思路。同一个实验，每个同学踩的坑都不一样：有人卡在外键顺序，有人卡在乱码，有人卡在事务隔离级别。把这些失败记录写进报告书末尾的“问题与解决”段落，反而是很自然的差异化素材。

我会在每份报告书最后保留一个小节，专门记录两三条实验过程中的具体问题。内容不用长，但要有真实的报错信息和调整过程。例如“第一次插入时报外键错误，检查发现子表数据先于父表插入，调整顺序后通过”，比任何模板都更有说服力，也能让阅卷人确信实验是你亲手做的。写报告书不需要追求完美无错，反而要把试错痕迹保留下来，这才是做实验的本来面目。

提交前我也会从指导老师视角从头读一遍，想象自己只有这份报告书，能不能把实验完整复现出来。如果中途需要猜环境、猜参数，就说明缺了说明。把这个习惯坚持几轮之后，报告书的质量会稳定下来。希望帮到你。

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