简介这是重庆大学数据库系统课程Project2的完整课设工程包面向高校选修数据库系统课程的学生以及需要完成同类大作业、课程设计或项目实训的开发者。资源内含可运行的Java源码与完整Maven工程配置已通过严格测试可直接复现完整项目效果。压缩包共51个文件大小约9.92MB文件类型涵盖XML配置、Java源文件、编译后的class与可执行jar包同时包含README说明与项目结构文件如.iml、.gitignore方便导入IDE后立即构建运行。目前已有65人浏览学习适合用于数据库系统项目设计、期末大作业或初期立项参考。资料包中提供了完整实现思路与可扩展的基础框架读者既能复刻原有功能也能在此基础上进一步扩展对理解数据库系统底层实现和工程组织均有帮助。1. 数据库系统 Project2 到底在练什么一份压缩包背后的完整数据库训练很多同学拿到这类课程包第一反应是“把 SQL 背一遍交上去”实际拆开才发现它考核的是从需求分析到 ER 建模、再由 ER 转关系模式、最后落到 MySQL 建表、导数据、写复杂查询与过程化 SQL 的完整链路。我复现过同类项目最深的感受是最容易丢分的不是查询写不出来而是设计文档和库表结构对不上、脚本换一台机器就跑不起来。这篇文章会按项目推进顺序讲清楚——解压后先确认什么、ER 怎么拆成表、导数据在哪个环节翻车、触发器和存储过程怎么调试最后用一遍清库重建验证交付。适合正在做数据库系统课程大作业的同学也适合想补上“设计到实现”这段实践的在职读者。2. 拿到压缩包先别急着写代码解压确认、目录结构与三个环境约定2.1 先解压zip 伪加密和中文文件名是最早的两个坑项目包以 zip 形式分发解压本该是最顺的一步但它恰恰是翻车率最高的环节。文件经过网盘转存、即时通讯传输压缩头里的加密标志位经常被第三方工具改动内容和标志对不上这就是常说的 zip 伪加密。你用 WinRAR 打开时提示要密码随便输什么都解不开文件属性里却看不出异常。判断伪加密不用装工具Python 自带 zipfile 就能做。把下面这段存成 check_zip.py和压缩包放同一目录再跑import zipfile zf zipfile.ZipFile(project2.zip) for info in zf.infolist(): encrypted bool(info.flag_bits 0x1) print(info.filename, info.flag_bits, encrypted)逻辑说明flag_bits 是 zip 目录项里的通用位标志最低位0x1置 1 代表“有加密标志”。如果打印出来的 encrypted 是 True但用 zf.read() 读文件内容时不需要密码也不报错就证明是伪加密。参数说明info.filename 是压缩包里的文件名info.flag_bits 是那 16 位的标志值encrypted 是我们按位与算出来的布尔结果。拿到这段输出后还可以顺手看下文件的解压后大小如果和压缩包体积差太多说明资料可能不完整别浪费时间继续装。伪加密的常规处理是直接换工具用 7-Zip 打开如果它不要求密码、能把内容正常拖出来就让它解压实在不行再用改动文件头的方式但课程资料涉及隐私我更推荐能不解就不解。如果 7-Zip 也要密码那是真加密只能找原作者要。第二个坑是中文文件名乱码。Windows 自带解压工具默认按 GBK 解压macOS 和 Linux 的 unzip 按 UTF-8 处理两边互相解压时中文名经常变成“鏁板瓧鏁版嵁”这类乱码。遇到这种情况不用慌先用 Python 看一眼原始字节import zipfile zf zipfile.ZipFile(project2.zip) for info in zf.infolist(): print(repr(info.filename))逻辑说明zipfile 默认优先按 UTF-8 解码文件名失败时才显示为乱码。repr() 会把不可见字符和转义序列原样打出来便于观察底层字节。参数说明info.filename 是解出来的字符串repr() 只是把它变成可检查的表示形式。看到形如 b\xca\xfd\xbe\xdd\xbf\xe2 的字节片段可以手动按 GBK 解码还原。我在处理这类乱码时不会一上来就批量改名而是先把文件名全部打印出来核对一遍确认哪些是真乱码、哪些本来就不影响使用再决定要不要写重命名脚本。2.2 目录结构与文件清单先分清脚本、文档与代码的边界一份完整的 Project2 压缩包目录结构通常是这个套路文件/目录内容对应评分点README.md 或 项目说明.docx题目要求、运行环境、交付形式所有部分的依据ER 图绘图文件 导出图实体、属性、联系的建模结果设计文档create.sql建库、建表 SQL含主外键数据库实现insert.sql测试数据通常几十到几百行数据验证query.sql题目要求的复杂查询SQL 能力trigger.sql / procedure.sql触发器、存储过程、事务加分项app/ 或 src/可选的应用层代码联调演示report.docx设计说明、结果截图最终评分主体先读哪个文件有讲究。我一般拿到包先开 README 或项目说明因为题目会写清楚提交格式是 SQL 文件还是报告正文、数据库限定 5.7 还是 8.0、查询要不要界面演示。这些约束直接决定后面要不要改造。如果包里有报告模板重点看它的章节目录出现“ER 图设计”“关系模式”“SQL 实现说明”“测试结果”这几个模块评分大概率就是按它们给分少一项代码再完整也会扣分。还有一种常见情况压缩包里同时出现 create.sql 和 create_new.sql或者一个叫 final、一个叫 final2说明提交者自己也迭代过好几版。这时候以 README 或报告里引用的文件为准别凭文件名猜。文件名 final 往往是最后改的那版但也不保证能跑导入前要打开看一遍建表语句是不是完整。2.3 环境对齐MySQL 8.0 的严格模式、utf8mb4 与客户端字符集脚本能不能在别人机器上原样跑起来取决于三个环境变量数据库版本、SQL 模式、字符集。三者不统一重定向导入大概率在中间某条语句报错。第一步先确认本机 MySQL 版本和 sql_modeSELECT VERSION(); SHOW VARIABLES LIKE sql_mode;逻辑说明VERSION() 返回当前 MySQL 版本。8.0 和 5.7 在默认值、排序规则、隐式转换上差异明显脚本如果是按旧版本语法写的在 8.0 上跑可能报错。sql_mode 影响哪些 SQL 会被当成错误而不是警告。参数说明mysql 8.0 默认 sql_mode 包含 ONLY_FULL_GROUP_BY 和 STRICT_TRANS_TABLES。前者要求 SELECT 里的非聚合列必须出现在 GROUP BY 中写统计查询时经常让新手意外报错后者会把“数据太长”“非法默认值”这类问题直接升级为错误导致 INSERT 中断。5.7 之前宽松模式下这些只是警告所以同一份脚本在两个版本上行为完全不同。第二步确认字符集。常见做法是命令行客户端连库时指定默认字符集避免 Windows 控制台代码页干扰mysql -h127.0.0.1 -uroot -p --default-character-setutf8mb4逻辑说明--default-character-setutf8mb4 让客户端发送的语句和返回的结果都按 utf8mb4 解释。utf8mb4 是真正的四字节 UTF-8能存生僻字和 emojiMySQL 里的 utf8 实际是 utf8mb3最多三字节插入四字节字符会直接报错。课程作业基本都要求 utf8mb4新建库别再写 utf8 或 gbk。参数说明-h127.0.0.1 是本地回环地址-uroot 指定用户-p 提示输密码。后面接着 重定向导入 SQL 文件时也要记得带 --default-character-setutf8mb4否则文件里的中文注释和数据可能出现编码错乱。建完库再做一次全局确认把当前库所有表的排序规则列出来SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema school;逻辑说明table_collation 是每张表的默认排序规则。同一个库如果出现 utf8mb4_unicode_ci 和 latin1_swedish_ci 混用JOIN 时字符集不一致会走隐式转换影响索引命中。课程作业数据量小性能问题不明显但评分老师很可能抽查建表语句写规范点没有坏处。参数说明table_schema 换成你实际库名示例里的 school 是下文一直沿用的库名按自己 create.sql 里的库名改。提示如果 create.sql 里同时包含 CREATE DATABASE 和 USE重定向导入时要留意当前连接的库是否被脚本切换避免后续表建到别的库里。3. 把需求翻译成关系模式从 ER 图到 3NF 的拆表操作3.1 从需求句子里提取实体、属性和联系Project2 需求文档基本是叙述体比如“学校开设若干课程每门课程由一位教师授课学生可以选修多门课程选课后登记成绩”。这段叙述里的名词要分成两类一类是业务对象的名称比如学生、课程、教师它们大概率是实体另一类是业务对象的属性比如学号、姓名、课程名、成绩它们挂在实体下面。判断标准是这个名词是否拥有独立标识、是否要被单独查询和统计。“学生”能被查“张三选了哪些课”所以它是实体“成绩”只依附在某个学生和某门课程的选课记录上没有独立存在意义所以它是“选修”这个联系的属性。下面给一个常见的学生选课模型对应的提取结果需求原文片段建模要素理由学生具有学号、姓名、性别、入学年份学生实体属性为学号、姓名、性别、入学年份学号是候选键每门课程有课程号、课程名、学分课程实体属性为课程号、课程名、学分课程号是候选键教师有工号、姓名、职称教师实体属性为工号、姓名、职称工号是候选键一位教师讲授若干门课程一门课程只有一位教师教师-课程是 1:N 联系联系基数影响外键放哪学生选修课程后获得成绩学生-课程 M:N 联系成绩是该联系的属性多对多必须建中间表提取时最常犯的错有两个。一是看到“课程名称”直接当成课程实体其实课程名只是课程号之外的一个属性二是看到“选修”就在学生表和课程表之间各加一条外键而不是建中间表。第二种错误会在第 3.2 节解释清楚。3.2 联系转外键的三条原则与一个反例ER 图画完之后真正写进 create.sql 的是关系模式。ER 转关系模式有三条基本规则Project2 里几乎每道题都用得上1:1 联系外键放在任意一端都可以看哪边查询更频繁。比如“班级和班长”这种 1:1通常把班长的学号放在班级表里。1:N 联系在 N 端加外键。比如教师和课程是 1:N课程表加 teacher_id 外键因为一门课只对应一个教师这个外键不会有冗余。M:N 联系必须新建中间表主键通常是两个外键的组合还可以追加联系的属性。学生和课程是 M:N所以要建 sc 表主键是 (student_id, course_id)。这里有个容易看走眼的情况教师和课程看起来是“一门课一个老师”但如果需求允许“一门课程由多个老师分段授课”它就变成 M:N。题目叙述里的措辞决定基数不能凭常识想当然。我见过同学按 1:N 建模后查询“某教师这学期所有教的课”时不得不去拆字符串非常痛苦。反例再补一个把教师工号放进课程表又把课程号放进教师表做成双向外键。这种设计看着“两边都能直接查”实际插入新教师时必须先插课程插新课程又必须先插教师互相依赖第一行数据就进不去。正确做法是始终保持单向引用1:N 只在 N 端放外键。3.3 用函数依赖检查范式Project2 对 3NF 的隐性要求关系模式设计完还要做一步自查是否满足 3NF。很多课程把 3NF 写进设计文档的评分标准但代码不会提醒你。检查方式是找函数依赖X → Y 表示 X 能唯一确定 Y。违反 2NF 的典型是中间表存在部分依赖违反 3NF 的典型是存在传递依赖。比如选课表设计成 (student_id, course_id, student_name, score)。student_name 由 student_id 单独决定和 course_id 无关这就是部分依赖根源是把学生属性混进了选课表。修改方式是拆回三张表student、course、scsc 只保留 (student_id, course_id, score)。再比如课程表里有 teacher_id 和 teacher_title职称由工号决定而工号由课程号决定形成传递依赖拆出 teacher 表后问题消失。这一步没有现成 SQL 能自动判定但可以先写几个检查重复行的查询验证候选键是否真的唯一-- 检查 sc 表是否有重复选课记录 SELECT student_id, course_id, COUNT(*) FROM sc GROUP BY student_id, course_id HAVING COUNT(*) 1;逻辑说明如果联合主键设计正确这个查询结果应该是空集。出现任何一行都说明主键定义错了。GROUP BY 按两个字段分组HAVING 过滤出组内行数大于 1 的组合。参数说明student_id 和 course_id 换成你自己实际的主键字段。如果 sc 表除了两个外键还有成绩字段主键必须是 (student_id, course_id) 联合主键不要在它俩之外另设自增 id 当主键再在这两列上加唯一索引——结果虽然接近但评审老师看到联合主键才认可你理解 M:N 建模。经验之谈设计文档里画 ER 图时联系旁边标的基数要和你最终建出来的外键方向严格一致。评分时老师很可能先看 ER 图再看 create.sql如果图上是 M:N表里却只有 student 表带 course_id一眼就是设计实现不一致扣分比 SQL 写错还狠。4. 建库、导数据与常见问题排查五个容易卡住的现场4.1 建库建表source 命令的路径和字符集拿到 create.sql 后最稳的导入方式是用命令行重定向。在 Windows 的 cmd、PowerShell 或 Linux/macOS 终端里执行mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS school DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 school create.sql mysql -uroot -p --default-character-setutf8mb4 school insert.sql逻辑说明第一条命令确保库存在指定 utf8mb4 字符集和 utf8mb4_unicode_ci 排序规则第二、三条用重定向把 SQL 文件喂给 mysql 客户端--default-character-set 保证客户端按 utf8mb4 解释文件内容。参数说明 是 shell 的重定向符。如果你是在 mysql 交互式客户端里对应的命令是 source 路径/create.sql二者行为有差别source 是在当前会话内逐条执行遇到报错会继续往下跑适合边执行边看日志重定向是一次性把整个脚本交给客户端遇到错误默认中断适合最终交付前的干净复现。建议调试用 source最后回归验证用重定向。导入时还要注意脚本里表的先后顺序。create.sql 里如果有外键必须先建被引用的主表再建从表。比如 sc 表引用 student 和 course那 student、course 必须出现在 sc 前面。如果顺序乱了第一遍导入会报外键约束错误。解决方式不是硬改脚本顺序而是先确认外键引用的表是否已经存在。SQL 层面也可以用 SET FOREIGN_KEY_CHECKS0 临时关掉外键检查导入完再开启但课程作业里建议少用因为评审老师看到这段可能怀疑你不理解外键机制。4.2 五个高频问题的排错记录问题一SQL 文件打开是中文乱码 表现create.sql 用 Navicat 打开注释和 INSERT 里的中文全是“銆?”一类乱码表结构能看懂数据没法看。 原因文件保存编码是 GBK/GB2312而 MySQL 按 utf8mb4 读取反过来文件是 UTF-8 但客户端用了 gbk 连接结果也一样。 解决先用 VS Code 或记事本看右下角编码标识。如果文件是 GBK另存为 UTF-8 再导入不想改文件的话导入前执行 SET NAMES gbk 也能对付。我一般统一把 SQL 文件改成 UTF-8 保存一劳永逸。问题二Unknown collation utf8mb4_0900_ai_ci 表现在 MySQL 5.7 或 MariaDB 上导入 8.0 生成的脚本建表语句直接报 unknown collation。 原因utf8mb4_0900_ai_ci 是 MySQL 8.0 新增的默认排序规则老版本不认识。 解决把建库建表语句里的 COLLATE 统一替换成 utf8mb4_unicode_ci用文本编辑器全局替换即可或者删掉 COLLATE 子句让表继承库级默认值效果相同。问题三Cannot add or update a child row: a foreign key constraint fails 表现insert.sql 导到某一行中断报外键约束失败。 原因导数据顺序和建表顺序不一致子表先插入了父表不存在的引用值或者 insert.sql 里用来做外键的字段类型和外键字段类型不匹配。 解决先查两张表已有的数据范围把插入顺序调整为先父后子。同时对比字段类型int 和 varchar 做外键时必须完全一致连 unsigned 也要一致类型不同也会报同一个错误。问题四Data too long for column 或 Incorrect datetime value 表现INSERT 报字段长度超限或者给 DATETIME 插入 0000-00-00 直接报错。 原因严格模式下字段长度不足或非法时间值被当成错误处理而不是警告。很多课程脚本是从旧教材抄的里面用了零日期8.0 严格模式不接受。 解决把字段长度调整到实际需要零日期改成 NULL 或合法日期。建表时给时间字段写 DEFAULT CURRENT_TIMESTAMP而不是 DEFAULT 0000-00-00 00:00:00。问题五客户端连不上报 Authentication plugin caching_sha2_password cannot be loaded 表现用旧版 Navicat、SQLyog 或老 JDBC 驱动连接 MySQL 8.0认证阶段卡住。 原因8.0 默认用 caching_sha2_password 认证插件老客户端不认。 解决升级客户端或驱动或者把账号认证方式改回 mysql_native_password执行后重连ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;逻辑说明ALTER USER 只影响指定账号的认证方式不改变密码本身。课程环境里没有安全合规压力为了让学生客户端能连上改回 native_password 是最省事的方案。参数说明 后面的部分要和连接时用的主机一致。如果客户端用 root% 连接这里就要写成 root%否则改了也白改。4.3 导数据后的自检行数、主键与外键完整性数据导入完成不要急着写查询。先做三分钟自检确认基础数据真的完整后面所有查询结果才有意义。SELECT COUNT(*) AS student_cnt FROM student; SELECT COUNT(*) AS course_cnt FROM course; SELECT COUNT(*) AS sc_cnt FROM sc; SELECT sc.* FROM sc LEFT JOIN student ON sc.student_id student.student_id WHERE student.student_id IS NULL;逻辑说明前三行分别是三张表的行数用于和 insert.sql 里预期的记录数对证最后一条是“孤儿记录”检查选出 sc 里存在但 student 里查不到的记录。LEFT JOIN 加 IS NULL 是标准查法。参数说明字段名换成你实际的列名。如果查出孤儿记录不要直接在表里 DELETE——先回到 insert.sql 看这条记录引用的主数据是不是漏导了漏导就补插确定是脏数据再删。课程作业里漏导比多导常见先补再删是安全顺序。另外如果 insert.sql 用了大量 INSERT INTO ... VALUES 逐条插入导完后顺手跑一下 SHOW INDEX FROM sc确认主键和索引真的建立。有的 create.sql 会漏掉主键定义表能建出来但查询优化器没有可用索引接下来 EXPLAIN 的结果会很难看。5. 复杂查询与过程化 SQL把 Project2 的加分项做实5.1 用 EXPLAIN 判断“真会”还是“背答案”Project2 通常有几道固定查询题没选过任何课的学生、每门课的最高分、超过平均分的记录、选课人数最多的课程。题目不同但套路类似。新手和老手的差别不在能不能写出结果而在能不能解释清楚性能。比如“没选过课的学生”NOT IN、NOT EXISTS、LEFT JOIN 三种写法都能出结果但评审老师想看到的是你会不会用 NOT EXISTSEXPLAIN SELECT s.student_id, s.name FROM student s WHERE NOT EXISTS ( SELECT 1 FROM sc WHERE sc.student_id s.student_id );逻辑说明NOT EXISTS 依赖子查询的索引判断“是否存在”找到一行立刻返回扫描量通常比 NOT IN 小。EXPLAIN 会输出访问类型、可能用到的索引、实际用到的索引、扫描行数等信息用来验证这条查询是不是真的走索引。参数说明看 EXPLAIN 输出重点看 type 和 key 两列。type 从好到差大致是 system const eq_ref ref range index ALL看到 ALL 说明是全表扫描。key 列显示实际用到的索引如果 key 为 NULL说明查询没有可用索引回去给 sc.student_id 建索引或调整表结构。rows 列是优化器估计要扫描的行数数据量一致的情况下rows 越小一般越快。写完查询后我习惯把 EXPLAIN 去掉真跑一遍看返回结果和题目预期是否一致。有的题要求“删除该学生后查询结果随之变化”那还要做一次 DELETE 加重查的回归别只贴一个静态结果。5.2 触发器OLD 和 NEW 的引用方式与循环触发触发器是 Project2 的常见加分项典型场景是限制选课人数或同步统计字段。写一个限制单个学生选课门数不超过 20 的触发器DELIMITER $$ CREATE TRIGGER trg_sc_before_insert BEFORE INSERT ON sc FOR EACH ROW BEGIN DECLARE v_cnt INT DEFAULT 0; SELECT COUNT(*) INTO v_cnt FROM sc WHERE student_id NEW.student_id; IF v_cnt 20 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 该学生选课数已达上限; END IF; END$$ DELIMITER ;逻辑说明BEFORE INSERT 表示在真正写入前先检查。NEW 引用将要插入的新行NEW.student_id 就是当前这条选课记录的学生号OLD 在 UPDATE 和 DELETE 触发器里引用旧行。IF 条件满足时用 SIGNAL 主动抛错MySQL 8.0 里这会中止当前语句并回滚。参数说明DELIMITER 不是 SQL 关键字而是 mysql 客户端的命令作用是把默认的分号临时改成 $$。如果不改整个触发器定义会被客户端按分号拆成好几段执行到第一个分号就完了。触发器定义跑完后一定要执行 DELIMITER ; 恢复否则后续所有 SQL 都会被当成一条语句直到遇见面包符才结束。触发器名 trg_sc_before_insert 建议按“表名_时机_操作”命名答辩时也方便讲。触发器最常见的翻车是循环触发在 sc 表的 INSERT 触发器里再次对 sc 做 INSERT 或 UPDATE会触发自己MySQL 报递归错误。解决思路有三个一是不在触发表里做 DML改为在另一张统计表里 UPDATE二是用会话变量做标志位三是把“选课人数统计”拆成显式的存储过程调用不用触发器。课程设计里我强烈建议第一种方案触发器只做校验和写别的表不要更新触发表本身。这个习惯能省下大量调试时间。测试触发器时先跑一条正常插入验证成功再刻意插入第 21 条记录验证报错。如果发现触发器没生效先查是否已有同名触发器占用执行 SHOW TRIGGERS 把旧的 DROP 掉再重建。5.3 存储过程、游标与事务多表更新不翻车的写法存储过程和触发器一样属于过程化 SQL很多课程把它放在加分项。常见考点是“输入学号输出该学生绩点”或“按成绩等级批量更新”。写一个带游标和 OUT 参数的 GPA 计算过程DELIMITER $$ CREATE PROCEDURE sp_calc_gpa( IN sid CHAR(10), OUT gpa DECIMAL(4,2) ) BEGIN DECLARE v_score DECIMAL(5,2); DECLARE v_sum DECIMAL(8,2) DEFAULT 0; DECLARE v_cnt INT DEFAULT 0; DECLARE done INT DEFAULT 0; DECLARE cur CURSOR FOR SELECT score FROM sc WHERE student_id sid; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_score; IF done 1 THEN LEAVE read_loop; END IF; SET v_sum v_sum (v_score / 10 - 5); SET v_cnt v_cnt 1; END LOOP; CLOSE cur; IF v_cnt 0 THEN SET gpa ROUND(v_sum / v_cnt, 2); ELSE SET gpa NULL; END IF; END$$ DELIMITER ;逻辑说明IN 参数是入口OUT 参数是返回值。游标 cur 逐行读出该学生的成绩CONTINUE HANDLER FOR NOT FOUND 在游标取完时把 done 置 1循环正常结束。这是游标写法里最容易漏的部分漏了它FETCH 到最后一条会抛异常而不是优雅退出。成绩转绩点的规则写在 v_score / 10 - 5 里60 分对应 1.090 分对应 4.0按课程要求替换公式即可。参数说明DECIMAL(5,2) 表示总分最大 999.99DECIMAL(4,2) 是绩点字段最大 99.99CHAR(10) 要和 student 表实际的学号类型一致。调用方式如下CALL sp_calc_gpa(20220001, gpa); SELECT gpa;gpa 是用户变量CALL 之后要立刻 SELECT 才能读到值。如果题目要求“批量给所有学生算绩点并更新 student 表”还得加事务在存储过程里用 START TRANSACTION 包住循环外的 UPDATECOMMIT 统一提交出错时 ROLLBACK。常见翻车点是循环内反复提交、中途报错后部分数据已更新、回滚失败。更隐蔽的问题是忘记在异常分支写 ROLLBACK过程异常退出后连接还挂着未提交事务表被锁到怀疑人生。存储过程里捕获异常的写法是 DECLARE EXIT HANDLERDECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END;逻辑说明EXIT HANDLER FOR SQLEXCEPTION 表示出现任何 SQL 异常就退出当前过程ROLLBACK 回滚事务RESIGNAL 把原始错误信息继续抛给调用方让你在客户端能看到真实报错。这个写法属于加分项但建议先跑通无异常分支再补异常处理否则出了问题很难分清是业务逻辑错还是异常分支错。6. 交作业前的回归验证从清库重建到评分点核对6.1 一次完整的清库重建交付前最后一晚我会强制自己把整个项目回滚到零再跑一遍模拟评审老师拿到文件后的动作。步骤固定删库、重建、导建表、导数据再跑一遍查询和触发器测试。mysql -uroot -p -e DROP DATABASE IF EXISTS school; mysql -uroot -p -e CREATE DATABASE school DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 school create.sql mysql -uroot -p --default-character-setutf8mb4 school insert.sql逻辑说明删除再重建保证不残留上一轮测试的状态。这套命令如果能无报错跑完说明脚本不依赖任何外部残留数据如果中途报错把报错信息截图放进报告同时修脚本不要带着报错交付。参数说明DROP DATABASE IF EXISTS 会删掉整个库执行前确认要保留的数据已经另存。6.2 对着评分点核对关键交付物最后一轮核对我固定用这张表过一遍评分点核对方式常见扣分点ER 图与关系模式图上每个联系都有对应外键或中间表图与表结构不一致建库建表清库重建无报错外键顺序、字符集混用查询结果与题目预期逐字段核对只贴代码不贴运行结果触发器/存储过程正常插入与异常插入都测试只测正常路径报告说明设计理由而非贴代码没有解释为什么这样拆表报告多说一句有些同学代码写得不错报告却把建表语句原样贴一遍没有任何设计说明。评审老师想看到的是“为什么 1:N 把外键放 N 端”“为什么这里用了中间表”“为什么成绩是联系的属性而不是学生表的属性”。每条写两三句话就能把设计文档分拿到手。以前我交类似项目时吃过亏代码能跑但报告没写设计理由被扣了分。从那以后我每次收尾都强制自己走一遍“清库→重建→跑查询→做一次异常插入测试”确认触发器和存储过程真的生效再打包。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/26 1:17:35 · 阅读 1.2k 数据库系统Project2实战：从ER建模到MySQL触发器与存储过程全解析
简介这是重庆大学数据库系统课程Project2的完整课设工程包面向高校选修数据库系统课程的学生以及需要完成同类大作业、课程设计或项目实训的开发者。资源内含可运行的Java源码与完整Maven工程配置已通过严格测试可直接复现完整项目效果。压缩包共51个文件大小约9.92MB文件类型涵盖XML配置、Java源文件、编译后的class与可执行jar包同时包含README说明与项目结构文件如.iml、.gitignore方便导入IDE后立即构建运行。目前已有65人浏览学习适合用于数据库系统项目设计、期末大作业或初期立项参考。资料包中提供了完整实现思路与可扩展的基础框架读者既能复刻原有功能也能在此基础上进一步扩展对理解数据库系统底层实现和工程组织均有帮助。1. 数据库系统 Project2 到底在练什么一份压缩包背后的完整数据库训练很多同学拿到这类课程包第一反应是“把 SQL 背一遍交上去”实际拆开才发现它考核的是从需求分析到 ER 建模、再由 ER 转关系模式、最后落到 MySQL 建表、导数据、写复杂查询与过程化 SQL 的完整链路。我复现过同类项目最深的感受是最容易丢分的不是查询写不出来而是设计文档和库表结构对不上、脚本换一台机器就跑不起来。这篇文章会按项目推进顺序讲清楚——解压后先确认什么、ER 怎么拆成表、导数据在哪个环节翻车、触发器和存储过程怎么调试最后用一遍清库重建验证交付。适合正在做数据库系统课程大作业的同学也适合想补上“设计到实现”这段实践的在职读者。2. 拿到压缩包先别急着写代码解压确认、目录结构与三个环境约定2.1 先解压zip 伪加密和中文文件名是最早的两个坑项目包以 zip 形式分发解压本该是最顺的一步但它恰恰是翻车率最高的环节。文件经过网盘转存、即时通讯传输压缩头里的加密标志位经常被第三方工具改动内容和标志对不上这就是常说的 zip 伪加密。你用 WinRAR 打开时提示要密码随便输什么都解不开文件属性里却看不出异常。判断伪加密不用装工具Python 自带 zipfile 就能做。把下面这段存成 check_zip.py和压缩包放同一目录再跑import zipfile zf zipfile.ZipFile(project2.zip) for info in zf.infolist(): encrypted bool(info.flag_bits 0x1) print(info.filename, info.flag_bits, encrypted)逻辑说明flag_bits 是 zip 目录项里的通用位标志最低位0x1置 1 代表“有加密标志”。如果打印出来的 encrypted 是 True但用 zf.read() 读文件内容时不需要密码也不报错就证明是伪加密。参数说明info.filename 是压缩包里的文件名info.flag_bits 是那 16 位的标志值encrypted 是我们按位与算出来的布尔结果。拿到这段输出后还可以顺手看下文件的解压后大小如果和压缩包体积差太多说明资料可能不完整别浪费时间继续装。伪加密的常规处理是直接换工具用 7-Zip 打开如果它不要求密码、能把内容正常拖出来就让它解压实在不行再用改动文件头的方式但课程资料涉及隐私我更推荐能不解就不解。如果 7-Zip 也要密码那是真加密只能找原作者要。第二个坑是中文文件名乱码。Windows 自带解压工具默认按 GBK 解压macOS 和 Linux 的 unzip 按 UTF-8 处理两边互相解压时中文名经常变成“鏁板瓧鏁版嵁”这类乱码。遇到这种情况不用慌先用 Python 看一眼原始字节import zipfile zf zipfile.ZipFile(project2.zip) for info in zf.infolist(): print(repr(info.filename))逻辑说明zipfile 默认优先按 UTF-8 解码文件名失败时才显示为乱码。repr() 会把不可见字符和转义序列原样打出来便于观察底层字节。参数说明info.filename 是解出来的字符串repr() 只是把它变成可检查的表示形式。看到形如 b\xca\xfd\xbe\xdd\xbf\xe2 的字节片段可以手动按 GBK 解码还原。我在处理这类乱码时不会一上来就批量改名而是先把文件名全部打印出来核对一遍确认哪些是真乱码、哪些本来就不影响使用再决定要不要写重命名脚本。2.2 目录结构与文件清单先分清脚本、文档与代码的边界一份完整的 Project2 压缩包目录结构通常是这个套路文件/目录内容对应评分点README.md 或 项目说明.docx题目要求、运行环境、交付形式所有部分的依据ER 图绘图文件 导出图实体、属性、联系的建模结果设计文档create.sql建库、建表 SQL含主外键数据库实现insert.sql测试数据通常几十到几百行数据验证query.sql题目要求的复杂查询SQL 能力trigger.sql / procedure.sql触发器、存储过程、事务加分项app/ 或 src/可选的应用层代码联调演示report.docx设计说明、结果截图最终评分主体先读哪个文件有讲究。我一般拿到包先开 README 或项目说明因为题目会写清楚提交格式是 SQL 文件还是报告正文、数据库限定 5.7 还是 8.0、查询要不要界面演示。这些约束直接决定后面要不要改造。如果包里有报告模板重点看它的章节目录出现“ER 图设计”“关系模式”“SQL 实现说明”“测试结果”这几个模块评分大概率就是按它们给分少一项代码再完整也会扣分。还有一种常见情况压缩包里同时出现 create.sql 和 create_new.sql或者一个叫 final、一个叫 final2说明提交者自己也迭代过好几版。这时候以 README 或报告里引用的文件为准别凭文件名猜。文件名 final 往往是最后改的那版但也不保证能跑导入前要打开看一遍建表语句是不是完整。2.3 环境对齐MySQL 8.0 的严格模式、utf8mb4 与客户端字符集脚本能不能在别人机器上原样跑起来取决于三个环境变量数据库版本、SQL 模式、字符集。三者不统一重定向导入大概率在中间某条语句报错。第一步先确认本机 MySQL 版本和 sql_modeSELECT VERSION(); SHOW VARIABLES LIKE sql_mode;逻辑说明VERSION() 返回当前 MySQL 版本。8.0 和 5.7 在默认值、排序规则、隐式转换上差异明显脚本如果是按旧版本语法写的在 8.0 上跑可能报错。sql_mode 影响哪些 SQL 会被当成错误而不是警告。参数说明mysql 8.0 默认 sql_mode 包含 ONLY_FULL_GROUP_BY 和 STRICT_TRANS_TABLES。前者要求 SELECT 里的非聚合列必须出现在 GROUP BY 中写统计查询时经常让新手意外报错后者会把“数据太长”“非法默认值”这类问题直接升级为错误导致 INSERT 中断。5.7 之前宽松模式下这些只是警告所以同一份脚本在两个版本上行为完全不同。第二步确认字符集。常见做法是命令行客户端连库时指定默认字符集避免 Windows 控制台代码页干扰mysql -h127.0.0.1 -uroot -p --default-character-setutf8mb4逻辑说明--default-character-setutf8mb4 让客户端发送的语句和返回的结果都按 utf8mb4 解释。utf8mb4 是真正的四字节 UTF-8能存生僻字和 emojiMySQL 里的 utf8 实际是 utf8mb3最多三字节插入四字节字符会直接报错。课程作业基本都要求 utf8mb4新建库别再写 utf8 或 gbk。参数说明-h127.0.0.1 是本地回环地址-uroot 指定用户-p 提示输密码。后面接着 重定向导入 SQL 文件时也要记得带 --default-character-setutf8mb4否则文件里的中文注释和数据可能出现编码错乱。建完库再做一次全局确认把当前库所有表的排序规则列出来SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema school;逻辑说明table_collation 是每张表的默认排序规则。同一个库如果出现 utf8mb4_unicode_ci 和 latin1_swedish_ci 混用JOIN 时字符集不一致会走隐式转换影响索引命中。课程作业数据量小性能问题不明显但评分老师很可能抽查建表语句写规范点没有坏处。参数说明table_schema 换成你实际库名示例里的 school 是下文一直沿用的库名按自己 create.sql 里的库名改。提示如果 create.sql 里同时包含 CREATE DATABASE 和 USE重定向导入时要留意当前连接的库是否被脚本切换避免后续表建到别的库里。3. 把需求翻译成关系模式从 ER 图到 3NF 的拆表操作3.1 从需求句子里提取实体、属性和联系Project2 需求文档基本是叙述体比如“学校开设若干课程每门课程由一位教师授课学生可以选修多门课程选课后登记成绩”。这段叙述里的名词要分成两类一类是业务对象的名称比如学生、课程、教师它们大概率是实体另一类是业务对象的属性比如学号、姓名、课程名、成绩它们挂在实体下面。判断标准是这个名词是否拥有独立标识、是否要被单独查询和统计。“学生”能被查“张三选了哪些课”所以它是实体“成绩”只依附在某个学生和某门课程的选课记录上没有独立存在意义所以它是“选修”这个联系的属性。下面给一个常见的学生选课模型对应的提取结果需求原文片段建模要素理由学生具有学号、姓名、性别、入学年份学生实体属性为学号、姓名、性别、入学年份学号是候选键每门课程有课程号、课程名、学分课程实体属性为课程号、课程名、学分课程号是候选键教师有工号、姓名、职称教师实体属性为工号、姓名、职称工号是候选键一位教师讲授若干门课程一门课程只有一位教师教师-课程是 1:N 联系联系基数影响外键放哪学生选修课程后获得成绩学生-课程 M:N 联系成绩是该联系的属性多对多必须建中间表提取时最常犯的错有两个。一是看到“课程名称”直接当成课程实体其实课程名只是课程号之外的一个属性二是看到“选修”就在学生表和课程表之间各加一条外键而不是建中间表。第二种错误会在第 3.2 节解释清楚。3.2 联系转外键的三条原则与一个反例ER 图画完之后真正写进 create.sql 的是关系模式。ER 转关系模式有三条基本规则Project2 里几乎每道题都用得上1:1 联系外键放在任意一端都可以看哪边查询更频繁。比如“班级和班长”这种 1:1通常把班长的学号放在班级表里。1:N 联系在 N 端加外键。比如教师和课程是 1:N课程表加 teacher_id 外键因为一门课只对应一个教师这个外键不会有冗余。M:N 联系必须新建中间表主键通常是两个外键的组合还可以追加联系的属性。学生和课程是 M:N所以要建 sc 表主键是 (student_id, course_id)。这里有个容易看走眼的情况教师和课程看起来是“一门课一个老师”但如果需求允许“一门课程由多个老师分段授课”它就变成 M:N。题目叙述里的措辞决定基数不能凭常识想当然。我见过同学按 1:N 建模后查询“某教师这学期所有教的课”时不得不去拆字符串非常痛苦。反例再补一个把教师工号放进课程表又把课程号放进教师表做成双向外键。这种设计看着“两边都能直接查”实际插入新教师时必须先插课程插新课程又必须先插教师互相依赖第一行数据就进不去。正确做法是始终保持单向引用1:N 只在 N 端放外键。3.3 用函数依赖检查范式Project2 对 3NF 的隐性要求关系模式设计完还要做一步自查是否满足 3NF。很多课程把 3NF 写进设计文档的评分标准但代码不会提醒你。检查方式是找函数依赖X → Y 表示 X 能唯一确定 Y。违反 2NF 的典型是中间表存在部分依赖违反 3NF 的典型是存在传递依赖。比如选课表设计成 (student_id, course_id, student_name, score)。student_name 由 student_id 单独决定和 course_id 无关这就是部分依赖根源是把学生属性混进了选课表。修改方式是拆回三张表student、course、scsc 只保留 (student_id, course_id, score)。再比如课程表里有 teacher_id 和 teacher_title职称由工号决定而工号由课程号决定形成传递依赖拆出 teacher 表后问题消失。这一步没有现成 SQL 能自动判定但可以先写几个检查重复行的查询验证候选键是否真的唯一-- 检查 sc 表是否有重复选课记录 SELECT student_id, course_id, COUNT(*) FROM sc GROUP BY student_id, course_id HAVING COUNT(*) 1;逻辑说明如果联合主键设计正确这个查询结果应该是空集。出现任何一行都说明主键定义错了。GROUP BY 按两个字段分组HAVING 过滤出组内行数大于 1 的组合。参数说明student_id 和 course_id 换成你自己实际的主键字段。如果 sc 表除了两个外键还有成绩字段主键必须是 (student_id, course_id) 联合主键不要在它俩之外另设自增 id 当主键再在这两列上加唯一索引——结果虽然接近但评审老师看到联合主键才认可你理解 M:N 建模。经验之谈设计文档里画 ER 图时联系旁边标的基数要和你最终建出来的外键方向严格一致。评分时老师很可能先看 ER 图再看 create.sql如果图上是 M:N表里却只有 student 表带 course_id一眼就是设计实现不一致扣分比 SQL 写错还狠。4. 建库、导数据与常见问题排查五个容易卡住的现场4.1 建库建表source 命令的路径和字符集拿到 create.sql 后最稳的导入方式是用命令行重定向。在 Windows 的 cmd、PowerShell 或 Linux/macOS 终端里执行mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS school DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 school create.sql mysql -uroot -p --default-character-setutf8mb4 school insert.sql逻辑说明第一条命令确保库存在指定 utf8mb4 字符集和 utf8mb4_unicode_ci 排序规则第二、三条用重定向把 SQL 文件喂给 mysql 客户端--default-character-set 保证客户端按 utf8mb4 解释文件内容。参数说明 是 shell 的重定向符。如果你是在 mysql 交互式客户端里对应的命令是 source 路径/create.sql二者行为有差别source 是在当前会话内逐条执行遇到报错会继续往下跑适合边执行边看日志重定向是一次性把整个脚本交给客户端遇到错误默认中断适合最终交付前的干净复现。建议调试用 source最后回归验证用重定向。导入时还要注意脚本里表的先后顺序。create.sql 里如果有外键必须先建被引用的主表再建从表。比如 sc 表引用 student 和 course那 student、course 必须出现在 sc 前面。如果顺序乱了第一遍导入会报外键约束错误。解决方式不是硬改脚本顺序而是先确认外键引用的表是否已经存在。SQL 层面也可以用 SET FOREIGN_KEY_CHECKS0 临时关掉外键检查导入完再开启但课程作业里建议少用因为评审老师看到这段可能怀疑你不理解外键机制。4.2 五个高频问题的排错记录问题一SQL 文件打开是中文乱码 表现create.sql 用 Navicat 打开注释和 INSERT 里的中文全是“銆?”一类乱码表结构能看懂数据没法看。 原因文件保存编码是 GBK/GB2312而 MySQL 按 utf8mb4 读取反过来文件是 UTF-8 但客户端用了 gbk 连接结果也一样。 解决先用 VS Code 或记事本看右下角编码标识。如果文件是 GBK另存为 UTF-8 再导入不想改文件的话导入前执行 SET NAMES gbk 也能对付。我一般统一把 SQL 文件改成 UTF-8 保存一劳永逸。问题二Unknown collation utf8mb4_0900_ai_ci 表现在 MySQL 5.7 或 MariaDB 上导入 8.0 生成的脚本建表语句直接报 unknown collation。 原因utf8mb4_0900_ai_ci 是 MySQL 8.0 新增的默认排序规则老版本不认识。 解决把建库建表语句里的 COLLATE 统一替换成 utf8mb4_unicode_ci用文本编辑器全局替换即可或者删掉 COLLATE 子句让表继承库级默认值效果相同。问题三Cannot add or update a child row: a foreign key constraint fails 表现insert.sql 导到某一行中断报外键约束失败。 原因导数据顺序和建表顺序不一致子表先插入了父表不存在的引用值或者 insert.sql 里用来做外键的字段类型和外键字段类型不匹配。 解决先查两张表已有的数据范围把插入顺序调整为先父后子。同时对比字段类型int 和 varchar 做外键时必须完全一致连 unsigned 也要一致类型不同也会报同一个错误。问题四Data too long for column 或 Incorrect datetime value 表现INSERT 报字段长度超限或者给 DATETIME 插入 0000-00-00 直接报错。 原因严格模式下字段长度不足或非法时间值被当成错误处理而不是警告。很多课程脚本是从旧教材抄的里面用了零日期8.0 严格模式不接受。 解决把字段长度调整到实际需要零日期改成 NULL 或合法日期。建表时给时间字段写 DEFAULT CURRENT_TIMESTAMP而不是 DEFAULT 0000-00-00 00:00:00。问题五客户端连不上报 Authentication plugin caching_sha2_password cannot be loaded 表现用旧版 Navicat、SQLyog 或老 JDBC 驱动连接 MySQL 8.0认证阶段卡住。 原因8.0 默认用 caching_sha2_password 认证插件老客户端不认。 解决升级客户端或驱动或者把账号认证方式改回 mysql_native_password执行后重连ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;逻辑说明ALTER USER 只影响指定账号的认证方式不改变密码本身。课程环境里没有安全合规压力为了让学生客户端能连上改回 native_password 是最省事的方案。参数说明 后面的部分要和连接时用的主机一致。如果客户端用 root% 连接这里就要写成 root%否则改了也白改。4.3 导数据后的自检行数、主键与外键完整性数据导入完成不要急着写查询。先做三分钟自检确认基础数据真的完整后面所有查询结果才有意义。SELECT COUNT(*) AS student_cnt FROM student; SELECT COUNT(*) AS course_cnt FROM course; SELECT COUNT(*) AS sc_cnt FROM sc; SELECT sc.* FROM sc LEFT JOIN student ON sc.student_id student.student_id WHERE student.student_id IS NULL;逻辑说明前三行分别是三张表的行数用于和 insert.sql 里预期的记录数对证最后一条是“孤儿记录”检查选出 sc 里存在但 student 里查不到的记录。LEFT JOIN 加 IS NULL 是标准查法。参数说明字段名换成你实际的列名。如果查出孤儿记录不要直接在表里 DELETE——先回到 insert.sql 看这条记录引用的主数据是不是漏导了漏导就补插确定是脏数据再删。课程作业里漏导比多导常见先补再删是安全顺序。另外如果 insert.sql 用了大量 INSERT INTO ... VALUES 逐条插入导完后顺手跑一下 SHOW INDEX FROM sc确认主键和索引真的建立。有的 create.sql 会漏掉主键定义表能建出来但查询优化器没有可用索引接下来 EXPLAIN 的结果会很难看。5. 复杂查询与过程化 SQL把 Project2 的加分项做实5.1 用 EXPLAIN 判断“真会”还是“背答案”Project2 通常有几道固定查询题没选过任何课的学生、每门课的最高分、超过平均分的记录、选课人数最多的课程。题目不同但套路类似。新手和老手的差别不在能不能写出结果而在能不能解释清楚性能。比如“没选过课的学生”NOT IN、NOT EXISTS、LEFT JOIN 三种写法都能出结果但评审老师想看到的是你会不会用 NOT EXISTSEXPLAIN SELECT s.student_id, s.name FROM student s WHERE NOT EXISTS ( SELECT 1 FROM sc WHERE sc.student_id s.student_id );逻辑说明NOT EXISTS 依赖子查询的索引判断“是否存在”找到一行立刻返回扫描量通常比 NOT IN 小。EXPLAIN 会输出访问类型、可能用到的索引、实际用到的索引、扫描行数等信息用来验证这条查询是不是真的走索引。参数说明看 EXPLAIN 输出重点看 type 和 key 两列。type 从好到差大致是 system const eq_ref ref range index ALL看到 ALL 说明是全表扫描。key 列显示实际用到的索引如果 key 为 NULL说明查询没有可用索引回去给 sc.student_id 建索引或调整表结构。rows 列是优化器估计要扫描的行数数据量一致的情况下rows 越小一般越快。写完查询后我习惯把 EXPLAIN 去掉真跑一遍看返回结果和题目预期是否一致。有的题要求“删除该学生后查询结果随之变化”那还要做一次 DELETE 加重查的回归别只贴一个静态结果。5.2 触发器OLD 和 NEW 的引用方式与循环触发触发器是 Project2 的常见加分项典型场景是限制选课人数或同步统计字段。写一个限制单个学生选课门数不超过 20 的触发器DELIMITER $$ CREATE TRIGGER trg_sc_before_insert BEFORE INSERT ON sc FOR EACH ROW BEGIN DECLARE v_cnt INT DEFAULT 0; SELECT COUNT(*) INTO v_cnt FROM sc WHERE student_id NEW.student_id; IF v_cnt 20 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 该学生选课数已达上限; END IF; END$$ DELIMITER ;逻辑说明BEFORE INSERT 表示在真正写入前先检查。NEW 引用将要插入的新行NEW.student_id 就是当前这条选课记录的学生号OLD 在 UPDATE 和 DELETE 触发器里引用旧行。IF 条件满足时用 SIGNAL 主动抛错MySQL 8.0 里这会中止当前语句并回滚。参数说明DELIMITER 不是 SQL 关键字而是 mysql 客户端的命令作用是把默认的分号临时改成 $$。如果不改整个触发器定义会被客户端按分号拆成好几段执行到第一个分号就完了。触发器定义跑完后一定要执行 DELIMITER ; 恢复否则后续所有 SQL 都会被当成一条语句直到遇见面包符才结束。触发器名 trg_sc_before_insert 建议按“表名_时机_操作”命名答辩时也方便讲。触发器最常见的翻车是循环触发在 sc 表的 INSERT 触发器里再次对 sc 做 INSERT 或 UPDATE会触发自己MySQL 报递归错误。解决思路有三个一是不在触发表里做 DML改为在另一张统计表里 UPDATE二是用会话变量做标志位三是把“选课人数统计”拆成显式的存储过程调用不用触发器。课程设计里我强烈建议第一种方案触发器只做校验和写别的表不要更新触发表本身。这个习惯能省下大量调试时间。测试触发器时先跑一条正常插入验证成功再刻意插入第 21 条记录验证报错。如果发现触发器没生效先查是否已有同名触发器占用执行 SHOW TRIGGERS 把旧的 DROP 掉再重建。5.3 存储过程、游标与事务多表更新不翻车的写法存储过程和触发器一样属于过程化 SQL很多课程把它放在加分项。常见考点是“输入学号输出该学生绩点”或“按成绩等级批量更新”。写一个带游标和 OUT 参数的 GPA 计算过程DELIMITER $$ CREATE PROCEDURE sp_calc_gpa( IN sid CHAR(10), OUT gpa DECIMAL(4,2) ) BEGIN DECLARE v_score DECIMAL(5,2); DECLARE v_sum DECIMAL(8,2) DEFAULT 0; DECLARE v_cnt INT DEFAULT 0; DECLARE done INT DEFAULT 0; DECLARE cur CURSOR FOR SELECT score FROM sc WHERE student_id sid; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_score; IF done 1 THEN LEAVE read_loop; END IF; SET v_sum v_sum (v_score / 10 - 5); SET v_cnt v_cnt 1; END LOOP; CLOSE cur; IF v_cnt 0 THEN SET gpa ROUND(v_sum / v_cnt, 2); ELSE SET gpa NULL; END IF; END$$ DELIMITER ;逻辑说明IN 参数是入口OUT 参数是返回值。游标 cur 逐行读出该学生的成绩CONTINUE HANDLER FOR NOT FOUND 在游标取完时把 done 置 1循环正常结束。这是游标写法里最容易漏的部分漏了它FETCH 到最后一条会抛异常而不是优雅退出。成绩转绩点的规则写在 v_score / 10 - 5 里60 分对应 1.090 分对应 4.0按课程要求替换公式即可。参数说明DECIMAL(5,2) 表示总分最大 999.99DECIMAL(4,2) 是绩点字段最大 99.99CHAR(10) 要和 student 表实际的学号类型一致。调用方式如下CALL sp_calc_gpa(20220001, gpa); SELECT gpa;gpa 是用户变量CALL 之后要立刻 SELECT 才能读到值。如果题目要求“批量给所有学生算绩点并更新 student 表”还得加事务在存储过程里用 START TRANSACTION 包住循环外的 UPDATECOMMIT 统一提交出错时 ROLLBACK。常见翻车点是循环内反复提交、中途报错后部分数据已更新、回滚失败。更隐蔽的问题是忘记在异常分支写 ROLLBACK过程异常退出后连接还挂着未提交事务表被锁到怀疑人生。存储过程里捕获异常的写法是 DECLARE EXIT HANDLERDECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END;逻辑说明EXIT HANDLER FOR SQLEXCEPTION 表示出现任何 SQL 异常就退出当前过程ROLLBACK 回滚事务RESIGNAL 把原始错误信息继续抛给调用方让你在客户端能看到真实报错。这个写法属于加分项但建议先跑通无异常分支再补异常处理否则出了问题很难分清是业务逻辑错还是异常分支错。6. 交作业前的回归验证从清库重建到评分点核对6.1 一次完整的清库重建交付前最后一晚我会强制自己把整个项目回滚到零再跑一遍模拟评审老师拿到文件后的动作。步骤固定删库、重建、导建表、导数据再跑一遍查询和触发器测试。mysql -uroot -p -e DROP DATABASE IF EXISTS school; mysql -uroot -p -e CREATE DATABASE school DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 school create.sql mysql -uroot -p --default-character-setutf8mb4 school insert.sql逻辑说明删除再重建保证不残留上一轮测试的状态。这套命令如果能无报错跑完说明脚本不依赖任何外部残留数据如果中途报错把报错信息截图放进报告同时修脚本不要带着报错交付。参数说明DROP DATABASE IF EXISTS 会删掉整个库执行前确认要保留的数据已经另存。6.2 对着评分点核对关键交付物最后一轮核对我固定用这张表过一遍评分点核对方式常见扣分点ER 图与关系模式图上每个联系都有对应外键或中间表图与表结构不一致建库建表清库重建无报错外键顺序、字符集混用查询结果与题目预期逐字段核对只贴代码不贴运行结果触发器/存储过程正常插入与异常插入都测试只测正常路径报告说明设计理由而非贴代码没有解释为什么这样拆表报告多说一句有些同学代码写得不错报告却把建表语句原样贴一遍没有任何设计说明。评审老师想看到的是“为什么 1:N 把外键放 N 端”“为什么这里用了中间表”“为什么成绩是联系的属性而不是学生表的属性”。每条写两三句话就能把设计文档分拿到手。以前我交类似项目时吃过亏代码能跑但报告没写设计理由被扣了分。从那以后我每次收尾都强制自己走一遍“清库→重建→跑查询→做一次异常插入测试”确认触发器和存储过程真的生效再打包。希望帮到你。本文还有配套的精品资源点击获取