简介这份数据库课程设计资源以「平行志愿模拟录取系统」为主题面向高校计算机相关专业学生及需要完成数据库课程设计的自学者帮助解决志愿填报、分数排序、投档录取等业务场景下的数据库建模与实现问题。资源包共969个文件整体约3.87MB以JavaScript、CSS、SCSS、Vue、TypeScript等前端资源为主辅以Java后端代码、SQL脚本、XML配置及少量文档与表格文件构成一套前后端分离的完整项目结构。其中SQL脚本可用于建库建表与数据初始化Java代码承载录取逻辑Vue与前端样式资源负责界面交互便于读者理解从需求分析到物理实现的完整链路。目前已有104人学习下载适合作为课程设计参考模板也可用于拆解平行志愿录取算法、借鉴数据库表结构设计与查询优化思路。1. 平行志愿模拟录取系统一个数据库课程设计到底该做成什么样每年到了期末计算机相关专业的学生都会接到一个数据库课程设计任务而平行志愿模拟录取系统几乎是出现频率最高的选题之一。原因很直接它天然包含多表关联、事务控制、并发写入、排名计算、批量更新这些数据库核心考点同时又贴近现实场景答辩时不容易被问倒。但问题也恰恰出在这里——很多人把它做成了一个能跑就行的增删改查页面数据库设计只有三四张表SQL 全靠 Java 拼字符串最后连自己都说不清这个系统到底解决了什么问题。这个选题真正值得做的点在于平行志愿录取本身就是一个典型的数据库工程问题。考生按分数排名、按志愿顺序检索、学校按计划数录取、退档后进入下一志愿——每一步都涉及事务边界、锁粒度、批量操作的性能。如果只是把数据塞进 MySQL 然后写几个 SELECT那和做一个通讯录没有本质区别。我见过太多课程设计最后沦为界面展示数据库部分只有一张考生表和一张学校表连志愿表都是硬编码在代码里的。所以这篇笔记的目标很明确把平行志愿模拟录取系统当成一个真实的数据库项目来做从表结构设计、核心 SQL 实现、事务与并发处理到批量录取的性能优化每一步都给出可复现的方案。适合正在做数据库课程设计的学生也适合想用一个完整案例练手 SQL 的开发者。你不需要先看完数据库原理教材跟着做就能跑通但如果你想拿高分中间几章的参数和边界条件值得反复看。2. 表结构设计与平行志愿的数据模型从考生到录取结果2.1 为什么不能用一张表存所有信息很多同学第一反应是设计一张大表考生号、姓名、分数、志愿1、志愿2、志愿3、志愿4、志愿5、志愿6、录取学校、录取专业。这种设计在数据量小的时候确实能跑但一旦要模拟真实录取流程立刻会遇到三个问题。第一志愿数量不确定。有的省份是 6 个平行志愿有的是 12 个有的新高考省份是 96 个。如果写死在列里改一个数字就要改表结构。第二录取过程需要记录每个志愿的检索状态——是未检索已投档被退档还是未达投档线。这些状态如果塞在同一张表里字段会膨胀到难以维护。第三学校端需要按专业分配计划数一个学校多个专业每个专业有独立的最低录取线这必须拆成独立的表。所以正确的做法是拆成五张核心表考生表、志愿表、院校专业表、录取计划表、录取结果表。下面直接给建表 SQL用的是 MySQL 8.0 语法字符集统一 utf8mb4。-- 考生表存储考生基本信息和总分 CREATE TABLE student ( student_id BIGINT PRIMARY KEY COMMENT 考生号, student_name VARCHAR(50) NOT NULL COMMENT 姓名, total_score DECIMAL(6,2) NOT NULL COMMENT 总分, subject_group VARCHAR(20) NOT NULL COMMENT 选科组别, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_score (total_score DESC), INDEX idx_group_score (subject_group, total_score DESC) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考生基本信息; -- 志愿表每个考生多条志愿记录按志愿序号排序 CREATE TABLE volunteer ( id BIGINT AUTO_INCREMENT PRIMARY KEY, student_id BIGINT NOT NULL COMMENT 考生号, volunteer_order INT NOT NULL COMMENT 志愿序号从1开始, college_code VARCHAR(20) NOT NULL COMMENT 院校代码, major_code VARCHAR(20) NOT NULL COMMENT 专业代码, status TINYINT DEFAULT 0 COMMENT 0未检索 1已投档 2被退档 3已录取, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_order (student_id, volunteer_order), INDEX idx_student (student_id), INDEX idx_college_major (college_code, major_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考生志愿表; -- 院校专业表每个专业的招生计划 CREATE TABLE major_plan ( id BIGINT AUTO_INCREMENT PRIMARY KEY, college_code VARCHAR(20) NOT NULL COMMENT 院校代码, college_name VARCHAR(100) NOT NULL COMMENT 院校名称, major_code VARCHAR(20) NOT NULL COMMENT 专业代码, major_name VARCHAR(100) NOT NULL COMMENT 专业名称, plan_count INT NOT NULL DEFAULT 0 COMMENT 计划招生人数, admitted_count INT NOT NULL DEFAULT 0 COMMENT 已录取人数, min_score DECIMAL(6,2) DEFAULT NULL COMMENT 当前最低录取分, UNIQUE KEY uk_college_major (college_code, major_code), INDEX idx_college (college_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT院校专业招生计划; -- 录取结果表最终录取记录 CREATE TABLE admission_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, student_id BIGINT NOT NULL COMMENT 考生号, college_code VARCHAR(20) NOT NULL COMMENT 院校代码, major_code VARCHAR(20) NOT NULL COMMENT 专业代码, volunteer_order INT NOT NULL COMMENT 第几志愿录取, admit_score DECIMAL(6,2) NOT NULL COMMENT 录取分数, admit_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student (student_id), INDEX idx_college_major (college_code, major_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT录取结果表;建表逻辑说明考生表的idx_score索引是为了后续按分数排名时避免全表排序志愿表的uk_student_order唯一键保证同一个考生不会出现重复的志愿序号major_plan表的admitted_count和min_score是冗余字段目的是在录取过程中快速判断某个专业是否已满、当前最低分是多少避免每次都去admission_result表做聚合查询。这是典型的空间换时间在模拟录取这种批量操作场景下非常值得。参数说明total_score用DECIMAL(6,2)而不是FLOAT因为分数比较和排名不能有浮点误差。volunteer_order用INT而不是TINYINT虽然 96 个志愿用 TINYINT 也够但考虑到不同省份可能扩展留出余量。status字段用TINYINT存状态码而不是字符串是为了索引效率和存储空间。2.2 平行志愿的排名规则怎么落到 SQL 里平行志愿的核心是分数优先、遵循志愿、一轮投档。翻译成数据库操作就是先按总分从高到低排序同分考生按语文、数学、外语单科成绩依次比较然后从第一名开始依次检索他的志愿列表第一个还有计划余额的专业就投档。这里有一个容易被忽略的点同分排序规则。很多课程设计只按总分排序结果同分考生谁先谁后完全看数据库返回顺序这在实际录取中是不允许的。所以考生表里还需要加单科成绩字段或者单独建一张成绩表。为了简化我直接在考生表里加三个字段ALTER TABLE student ADD COLUMN chinese_score DECIMAL(5,2) DEFAULT 0 COMMENT 语文成绩; ALTER TABLE student ADD COLUMN math_score DECIMAL(5,2) DEFAULT 0 COMMENT 数学成绩; ALTER TABLE student ADD COLUMN english_score DECIMAL(5,2) DEFAULT 0 COMMENT 外语成绩;然后排名查询可以这样写SELECT student_id, student_name, total_score, ROW_NUMBER() OVER ( ORDER BY total_score DESC, chinese_score DESC, math_score DESC, english_score DESC ) AS rank_no FROM student WHERE subject_group 物理组 ORDER BY rank_no;ROW_NUMBER()是 MySQL 8.0 引入的窗口函数比用户变量写法更稳定也不会因为优化器行为变化导致排名错乱。如果你用的是 MySQL 5.7需要用变量模拟但那种写法在数据量大时性能很差建议直接升级到 8.0。subject_group条件不能少因为新高考省份不同选科组是分开排名的。提示如果考生总数超过 10 万ROW_NUMBER()的全表排序会消耗大量临时表空间。可以考虑先把排名结果物化到一张临时表里加索引后再做后续检索。3. 模拟录取的核心流程从投档到退档的 SQL 实现3.1 一轮投档的存储过程怎么写平行志愿录取最核心的逻辑是按排名顺序遍历考生对每个考生按志愿顺序遍历找到第一个admitted_count plan_count的专业执行投档。这个过程如果放在应用层用 Java 循环会产生大量往返数据库的查询性能很差。更好的做法是写一个存储过程在数据库内部完成。下面是一个简化版的投档存储过程用游标遍历排名后的考生逐志愿检查计划余额DELIMITER $$ CREATE PROCEDURE simulate_admission(IN p_group VARCHAR(20)) BEGIN DECLARE done INT DEFAULT 0; DECLARE v_student_id BIGINT; DECLARE v_score DECIMAL(6,2); DECLARE v_order INT; DECLARE v_college VARCHAR(20); DECLARE v_major VARCHAR(20); DECLARE v_plan INT; DECLARE v_admitted INT; -- 游标按排名顺序取考生 DECLARE cur_student CURSOR FOR SELECT student_id, total_score FROM student WHERE subject_group p_group ORDER BY total_score DESC, chinese_score DESC, math_score DESC, english_score DESC; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur_student; read_loop: LOOP FETCH cur_student INTO v_student_id, v_score; IF done THEN LEAVE read_loop; END IF; -- 检查该考生是否已被录取 IF NOT EXISTS (SELECT 1 FROM admission_result WHERE student_id v_student_id) THEN -- 遍历该考生的志愿 BEGIN DECLARE cur_vol CURSOR FOR SELECT volunteer_order, college_code, major_code FROM volunteer WHERE student_id v_student_id AND status 0 ORDER BY volunteer_order; DECLARE done_vol INT DEFAULT 0; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done_vol 1; OPEN cur_vol; vol_loop: LOOP FETCH cur_vol INTO v_order, v_college, v_major; IF done_vol THEN LEAVE vol_loop; END IF; -- 锁定该专业计划行防止并发超录 SELECT plan_count, admitted_count INTO v_plan, v_admitted FROM major_plan WHERE college_code v_college AND major_code v_major FOR UPDATE; IF v_admitted v_plan THEN -- 投档成功 INSERT INTO admission_result (student_id, college_code, major_code, volunteer_order, admit_score) VALUES (v_student_id, v_college, v_major, v_order, v_score); UPDATE major_plan SET admitted_count admitted_count 1, min_score LEAST(IFNULL(min_score, v_score), v_score) WHERE college_code v_college AND major_code v_major; UPDATE volunteer SET status 3 WHERE student_id v_student_id AND volunteer_order v_order; LEAVE vol_loop; ELSE -- 该志愿计划已满标记为被退档 UPDATE volunteer SET status 2 WHERE student_id v_student_id AND volunteer_order v_order; END IF; END LOOP; CLOSE cur_vol; END; END IF; END LOOP; CLOSE cur_student; END$$ DELIMITER ;这段存储过程的逻辑说明外层游标按排名取考生内层游标按志愿顺序取该考生的志愿。对每个志愿先用SELECT ... FOR UPDATE锁定major_plan对应行然后判断admitted_count plan_count。如果还有余额插入录取结果、更新计划表的已录取人数和最低分、把志愿状态改为已录取然后跳出内层循环。如果计划已满把该志愿状态改为被退档继续检查下一个志愿。参数说明p_group是选科组别因为不同组别分开录取。FOR UPDATE是必须的否则多个录取线程同时操作同一个专业会导致超录。LEAST(IFNULL(min_score, v_score), v_score)保证最低分始终记录当前录取的最低分数。注意存储过程里嵌套游标在 MySQL 中是允许的但内层游标的CONTINUE HANDLER会覆盖外层的done变量。上面的写法用done_vol单独声明避免了这个问题。如果你把两个游标的 handler 写成同一个变量外层循环会在第一次内层结束后就退出这是血泪教训。3.2 用事务保证投档的原子性上面的存储过程默认每条 SQL 自动提交这在模拟录取场景下是危险的。如果插入录取结果成功但更新计划表失败就会出现录取了但计划没扣的不一致。所以需要在存储过程外层包一个事务或者在调用时显式开启。START TRANSACTION; CALL simulate_admission(物理组); COMMIT;如果中途出错ROLLBACK会撤销所有未提交的修改。但要注意存储过程内部的FOR UPDATE锁在事务提交前不会释放如果考生数量很大整个录取过程可能持有大量行锁导致其他会话等待超时。常见的做法是分批提交比如每处理 1000 个考生提交一次。但分批提交会破坏一轮投档的原子性——如果系统在批次之间崩溃恢复后需要知道哪些考生已经处理过。折中方案是在volunteer表里加一个processed标记每批处理前先查出未处理的考生处理完一批后更新标记并提交。这样即使崩溃重启后也能从断点继续。这个设计在真实录取系统中很常见课程设计里加上会让答辩老师眼前一亮。ALTER TABLE volunteer ADD COLUMN processed TINYINT DEFAULT 0 COMMENT 是否已处理;然后存储过程里每次处理完一个考生更新他的所有志愿processed 1。外层用循环分批调用每批 1000 人。具体实现可以根据你的数据量调整批次大小一般 500 到 2000 之间比较合适。4. 避坑与排查平行志愿模拟录取最容易翻车的 5 个地方4.1 同分考生排名不稳定每次跑结果不一样现象同样的数据跑两次录取同分考生的录取结果不同。原因ORDER BY total_score DESC没有指定同分时的次级排序字段MySQL 返回顺序取决于执行计划和存储引擎不保证稳定。解决在ORDER BY里加上单科成绩字段并且确保这些字段有索引或者至少参与排序。如果单科成绩也完全相同可以再加考生号作为最终排序键保证绝对稳定。4.2 并发投档导致超录计划数被突破现象某个专业计划招 10 人最终录取了 12 人。原因多个录取线程同时读到admitted_count 9都判断还有余额然后各自插入录取结果。解决在SELECT计划行时加FOR UPDATE把行锁住第二个线程会等待第一个线程提交后再读此时admitted_count已经变成 10就不会再录。如果用的是READ COMMITTED隔离级别还要注意FOR UPDATE的加锁范围确保锁的是具体行而不是间隙。4.3 志愿状态更新遗漏退档考生卡在原地现象考生所有志愿都满了但志愿状态还是未检索没有标记为被退档。原因内层游标在计划已满时只更新了当前志愿状态但循环结束后没有统一处理。解决在内层循环结束后检查该考生是否被录取如果没有把所有未检索的志愿批量更新为被退档。或者更简单在每次计划已满时立即更新当前志愿状态循环结束后再补一条UPDATE volunteer SET status 2 WHERE student_id ? AND status 0。4.4 存储过程调试困难出错不知道哪一行现象调用存储过程后报错但错误信息只显示存储过程执行失败没有具体行号。原因MySQL 存储过程的错误堆栈不友好。解决在关键步骤加SELECT输出中间变量或者用DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获异常并写入日志表。日志表至少包含步骤名、考生号、志愿序号、错误码、错误信息、时间戳。这样出问题可以直接查表定位。CREATE TABLE admission_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, step_name VARCHAR(50), student_id BIGINT, vol_order INT, error_code INT, error_msg VARCHAR(500), log_time DATETIME DEFAULT CURRENT_TIMESTAMP );4.5 批量插入录取结果时性能骤降现象前 1000 条录取结果插入很快后面越来越慢。原因admission_result表的uk_student唯一索引在每次插入时都要检查数据量大了之后 B 树深度增加插入变慢。另外如果每次插入都自动提交磁盘 I/O 会成为瓶颈。解决把自动提交关掉每 500 条提交一次或者先用INSERT INTO ... SELECT批量生成结果再统一更新计划表。对于课程设计的数据量通常几千到几万考生分批提交已经足够。如果数据量真的很大可以考虑先删除唯一索引插入完成后再重建但这样会失去唯一性保护需要自己保证不重复。5. 进阶技巧用窗口函数和批量更新把录取速度提上来前面给的存储过程是逐考生、逐志愿处理的逻辑清晰但性能一般。如果你想让课程设计在答辩时更有说服力可以试试用窗口函数和批量更新来优化。核心思路是不再逐条判断而是先把所有考生的有效志愿算出来再一次性投档。具体做法分三步。第一步用窗口函数给每个考生的每个志愿计算一个优先级考生排名越靠前、志愿序号越小优先级越高。第二步对每个专业按优先级排序取前plan_count条作为录取记录。第三步把录取记录批量插入结果表同时更新计划表。-- 第一步计算每个志愿的全局优先级 WITH ranked_volunteer AS ( SELECT v.student_id, v.volunteer_order, v.college_code, v.major_code, s.total_score, ROW_NUMBER() OVER ( ORDER BY s.total_score DESC, s.chinese_score DESC, s.math_score DESC, s.english_score DESC ) AS student_rank, ROW_NUMBER() OVER ( PARTITION BY v.college_code, v.major_code ORDER BY s.total_score DESC, s.chinese_score DESC, s.math_score DESC, s.english_score DESC, v.volunteer_order ) AS major_rank FROM volunteer v JOIN student s ON v.student_id s.student_id WHERE v.status 0 AND s.subject_group 物理组 ), -- 第二步每个专业取前 plan_count 名 admitted AS ( SELECT rv.* FROM ranked_volunteer rv JOIN major_plan mp ON rv.college_code mp.college_code AND rv.major_code mp.major_code WHERE rv.major_rank mp.plan_count ) -- 第三步插入录取结果 INSERT INTO admission_result (student_id, college_code, major_code, volunteer_order, admit_score) SELECT student_id, college_code, major_code, volunteer_order, total_score FROM admitted ON DUPLICATE KEY UPDATE admit_score VALUES(admit_score);这个写法的好处是只用一条 SQL 就完成了投档避免了游标逐行处理的性能问题。但有一个关键点需要注意major_rank是按专业分区计算的它假设每个考生只会被一个专业录取。如果同一个考生在多个专业都排进了前plan_count他会同时出现在多个专业的录取列表里导致重复录取。所以还需要加一个去重步骤对每个考生只保留major_rank最小的那条记录。-- 去重每个考生只保留最优录取 SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY student_id ORDER BY major_rank) AS final_rank FROM admitted ) t WHERE final_rank 1;这个优化方案在数据量超过 5 万考生时优势明显从原来的几分钟缩短到几秒。但它的逻辑比游标版本复杂调试也更困难。我的习惯是先用游标版本跑通逻辑确认结果正确再用窗口函数版本做性能优化两个版本的结果必须完全一致才算通过。如果时间紧游标版本足够应付课程设计如果想拿高分或者数据量大窗口函数版本值得花时间调。最后说一个我踩过的坑窗口函数里的ORDER BY如果字段没有索引MySQL 会创建临时表并排序数据量大时可能直接爆磁盘。所以student表的idx_group_score索引一定要建而且顺序要和ORDER BY一致。另外ON DUPLICATE KEY UPDATE在批量插入时如果冲突太多性能会下降可以考虑先用INSERT IGNORE再补更新。这些细节在课程设计报告里写清楚比多画几个界面截图有用得多。希望帮到你。本文还有配套的精品资源点击获取