学生选课管理系统（含数据库、源码）：从建表到抢课不崩的完整落地路径

简介这是一套面向计算机专业学生与Java初学者设计的学生选课管理系统完整学习资料围绕数据库设计、Java Web开发与学生信息管理三大方向帮助读者通过真实项目理解选课业务逻辑与MVC架构的落地方式。资源包共15个文件约8.56MB包含8张运行截图、3份说明文本、2个源码压缩包、1份课堂设计文档和1份SQL数据库文件覆盖从建库建表到项目部署的完整链路。其中SQL文件提供学生表、课程表、选课表等核心结构源码包展示Servlet、JSP与JDBC的整合实现截图与文档则辅助理解界面布局和设计思路。目前已有5368人学习下载适合作为课程设计、毕业设计或Java Web入门练手项目读者可据此掌握选课冲突处理、成绩查询、权限管理等典型功能的实现方法并积累数据库备份与性能优化的实践经验。1. 学生选课管理系统含数据库、源码从建表到抢课不崩的完整落地路径每学期选课开放那几分钟教务系统卡死、课程余量显示错乱、同一学生选上两门时间冲突的课——这些不是段子是很多自研或外包教务模块的真实翻车现场。学生选课管理系统含数据库、源码这个标题核心就是一套能跑通「学生选课、教师开课、管理员管课」三端流程的 Web 应用外加一份设计合理的数据库脚本。它解决的是选课并发、余量扣减、时间冲突校验这三类硬问题适合两类人一是要交课程设计或做毕设的学生二是需要给中小规模教学场景搭一套轻量选课工具的后端开发者。下面我按「库怎么建 → 接口怎么写 → 并发怎么扛 → 坑在哪」的顺序把一套可复现的方案讲透。2. 数据库设计选课系统的地基怎么打选课系统崩不崩八成看表结构。很多人一上来就写 Java 或 Python 代码表随便建几张结果做到一半发现「一个学生选多门课」和「一门课被多个学生选」是多对多关系临时加中间表字段名对不上返工重来。这一章先把库设计清楚后面写代码才不会反复改。2.1 五张核心表与字段取舍一套最小可用的选课系统核心是五张表学生表、教师表、课程表、开课表教学班、选课记录表。注意「课程」和「开课」必须分开——课程是「数据结构」这门课本身开课是「2024 秋季张老师周三第 3-4 节的数据结构」同一门课可以开多个班这是新手最容易合并错的地方。-- 学生表学号做主键避免用自增 id 对外暴露 CREATE TABLE student ( student_no VARCHAR(20) PRIMARY KEY COMMENT 学号, name VARCHAR(50) NOT NULL, grade SMALLINT NOT NULL COMMENT 入学年份, major VARCHAR(50) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 课程表课程本身的元信息不含时间地点 CREATE TABLE course ( course_id VARCHAR(20) PRIMARY KEY COMMENT 课程代码, course_name VARCHAR(100) NOT NULL, credit DECIMAL(3,1) NOT NULL COMMENT 学分, dept VARCHAR(50) NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 开课表真正被选的对象含容量、时间、教师 CREATE TABLE course_section ( section_id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id VARCHAR(20) NOT NULL, teacher_no VARCHAR(20) NOT NULL, semester VARCHAR(20) NOT NULL COMMENT 如 2024-FALL, capacity INT NOT NULL DEFAULT 60, selected INT NOT NULL DEFAULT 0 COMMENT 已选人数, day_of_week TINYINT NOT NULL COMMENT 1-7, start_slot TINYINT NOT NULL COMMENT 第几节开始, end_slot TINYINT NOT NULL, UNIQUE KEY uk_course_teacher_term (course_id, teacher_no, semester), KEY idx_semester (semester) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 选课记录表学生与开课的多对多联合唯一防重复选 CREATE TABLE enrollment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL, section_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1已选 2已退, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_section (student_no, section_id), KEY idx_section (section_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段取舍上有几个关键点。course_section里冗余了一个selected字段而不是每次去enrollment表 count这是为了抢课时的性能——count 在几千条记录下还行上万条并发时就是灾难。enrollment用status软删除而不是物理删除退课记录留痕方便审计和统计。uk_student_section这个联合唯一索引是防重复选的最后一道防线应用层判断之外数据库再兜一层双保险。2.2 时间冲突怎么在库层面表达时间冲突校验是选课系统里最容易被低估的逻辑。常见做法是把一周切成若干节次比如每天 12 节用day_of_week start_slot end_slot表示一个时间段。判断两门课是否冲突就是判断「同一天」且「时间段有重叠」。-- 查询某学生已选课程中与目标时间段冲突的记录 SELECT e.section_id, cs.course_id, cs.day_of_week, cs.start_slot, cs.end_slot FROM enrollment e JOIN course_section cs ON e.section_id cs.section_id WHERE e.student_no ? AND e.status 1 AND cs.semester ? AND cs.day_of_week ? -- 同一天 AND cs.start_slot ? -- 目标结束节次 AND cs.end_slot ?; -- 目标开始节次这个重叠判断的写法要记牢A.start B.end AND A.end B.start两个条件缺一不可。我见过有人只写A.start B.start AND A.end B.end结果「包含关系」的冲突漏判了——比如已选课是 1-4 节新课是 2-3 节按错误写法就查不出来。参数上semester必须带上否则跨学期比对会误判冲突。2.3 索引与约束的取舍清单对象索引/约束作用是否必须enrollmentuk_student_section防重复选课必须enrollmentidx_section按开课统计人数必须course_sectionidx_semester按学期筛课必须course_sectionuk_course_teacher_term防同教师重复开课建议student主键 student_no学号查询必须索引不是越多越好。enrollment表写入频繁每多一个索引选课时的写入就多一份开销。上面这几个是经过权衡的查询路径覆盖到了写入放大也可控。至于外键约束我一般不在高并发写入的表上加物理外键改用应用层保证一致性因为外键检查在抢课高峰会带来额外的锁竞争——这是血泪经验早期版本加了外键压测时 QPS 直接掉三成。3. 后端接口实现选课、退课、查课的最小闭环库建好了接下来是接口。这一章用 Python Flask 写一套最小闭环重点不是框架本身而是选课这个动作里「校验 → 扣减 → 落库」的顺序和事务边界。换成 Java Spring Boot 或 Node.js 思路完全一样把 SQL 和事务语义搬过去即可。3.1 选课接口的完整事务逻辑选课接口要在一个事务里完成四件事查余量、查冲突、扣余量、写记录。顺序不能乱任何一步失败都要回滚。from flask import Flask, request, jsonify import pymysql app Flask(__name__) def get_conn(): return pymysql.connect( host127.0.0.1, userapp, password***, databasecourse_sys, charsetutf8mb4, autocommitFalse, cursorclasspymysql.cursors.DictCursor ) app.route(/api/enroll, methods[POST]) def enroll(): student_no request.json[student_no] section_id request.json[section_id] conn get_conn() try: with conn.cursor() as cur: # 1. 行锁锁定该开课记录防止并发超卖 cur.execute( SELECT capacity, selected, semester, day_of_week, start_slot, end_slot FROM course_section WHERE section_id %s FOR UPDATE, (section_id,)) sec cur.fetchone() if not sec: return jsonify(code404, msg开课不存在), 404 if sec[selected] sec[capacity]: return jsonify(code409, msg课程已满), 409 # 2. 时间冲突校验 cur.execute( SELECT COUNT(*) AS c FROM enrollment e JOIN course_section cs ON e.section_id cs.section_id WHERE e.student_no %s AND e.status 1 AND cs.semester %s AND cs.day_of_week %s AND cs.start_slot %s AND cs.end_slot %s, (student_no, sec[semester], sec[day_of_week], sec[end_slot], sec[start_slot])) if cur.fetchone()[c] 0: return jsonify(code409, msg时间冲突), 409 # 3. 扣减余量 写选课记录 cur.execute( UPDATE course_section SET selected selected 1 WHERE section_id %s, (section_id,)) cur.execute( INSERT INTO enrollment (student_no, section_id, status) VALUES (%s, %s, 1), (student_no, section_id)) conn.commit() return jsonify(code0, msg选课成功) except pymysql.err.IntegrityError: conn.rollback() return jsonify(code409, msg请勿重复选课), 409 except Exception as e: conn.rollback() return jsonify(code500, msg系统繁忙), 500 finally: conn.close()逻辑说明第一步的FOR UPDATE是关键它给这一行开课记录加了排他锁同一时刻只有一个事务能读到并修改selected从根上杜绝超卖。第二步冲突校验放在锁内保证读到的是最新已选状态。第三步扣减和写入在同一个事务要么全成要么全败。参数上autocommitFalse必须显式设置否则每条 SQL 自动提交事务就形同虚设。3.2 退课接口与余量回补退课不是简单删记录而是把status改成 2 并把selected减一同样要在一个事务里。app.route(/api/drop, methods[POST]) def drop(): student_no request.json[student_no] section_id request.json[section_id] conn get_conn() try: with conn.cursor() as cur: # 只允许退「已选」状态的记录防止重复退课把余量减穿 cur.execute( UPDATE enrollment SET status 2 WHERE student_no %s AND section_id %s AND status 1, (student_no, section_id)) if cur.rowcount 0: conn.rollback() return jsonify(code409, msg无有效选课记录), 409 cur.execute( UPDATE course_section SET selected selected - 1 WHERE section_id %s AND selected 0, (section_id,)) conn.commit() return jsonify(code0, msg退课成功) except Exception: conn.rollback() return jsonify(code500, msg系统繁忙), 500 finally: conn.close()这里UPDATE ... WHERE status 1的rowcount判断很重要。如果学生重复点退课第二次rowcount为 0直接回滚不会把selected减成负数。selected 0这个条件也是兜底防止任何异常路径下余量被减穿。3.3 查课接口的分页与筛选查课接口要支持按学期、院系、关键字筛选并分页。分页别用LIMIT offset, size在大偏移量下会慢常见做法是游标分页但选课场景数据量不大LIMIT够用。app.route(/api/sections, methods[GET]) def list_sections(): semester request.args.get(semester, ) keyword request.args.get(keyword, ) page int(request.args.get(page, 1)) size min(int(request.args.get(size, 20)), 100) # 上限 100 防拖库 offset (page - 1) * size conn get_conn() try: with conn.cursor() as cur: sql (SELECT cs.section_id, c.course_name, cs.teacher_no, cs.capacity, cs.selected, cs.day_of_week, cs.start_slot, cs.end_slot FROM course_section cs JOIN course c ON cs.course_id c.course_id WHERE cs.semester %s) params [semester] if keyword: sql AND c.course_name LIKE %s params.append(f%{keyword}%) sql ORDER BY cs.section_id LIMIT %s OFFSET %s params [size, offset] cur.execute(sql, params) return jsonify(code0, datacur.fetchall()) finally: conn.close()size上限设 100 是防止有人传size100000把整库拖出来。LIKE %keyword%前置通配符用不上索引数据量大时要换成全文索引或搜索引擎但选课系统课程量通常几百到几千够用。4. 并发抢课为什么你的系统一到点就崩选课系统最刺激的时刻就是开放瞬间几百上千人同时点同一门热门课。这一章讲清楚并发下会出什么问题、怎么压测、怎么优化。很多人本地测得好好的一上线就超卖问题全出在并发控制上。4.1 超卖是怎么发生的假设课程容量 60当前已选 59两个请求同时进来。如果代码是「先查余量再扣减」且没有锁两个请求都查到 59 60都执行扣减结果selected变成 61超卖一门。这就是典型的竞态条件。解决办法有三种按可靠性排序数据库行锁FOR UPDATE、乐观锁版本号或selected capacity条件更新、Redis 预扣减。中小系统用行锁最稳实现简单代价是并发度受限。4.2 乐观锁方案与压测对比如果不想用行锁可以用条件更新做乐观锁把「查余量」和「扣减」合并成一条 SQL-- 只有余量未满时才扣减rowcount 为 0 说明没抢到 UPDATE course_section SET selected selected 1 WHERE section_id %s AND selected capacity;应用层判断rowcount为 1 说明扣减成功为 0 说明已满。这个方案不用显式加锁并发度更高但要注意扣减成功后如果写enrollment失败余量就白扣了所以仍要放在事务里失败回滚。我用 200 并发压过两种方案行锁方案 QPS 约 800乐观锁约 1500但乐观锁在极端竞争下失败重试多实际成功率要结合重试逻辑看。4.3 用脚本模拟并发抢课压测不用真找人点写个脚本模拟并发就行。下面用 Python 的线程池打 200 个并发请求。import requests from concurrent.futures import ThreadPoolExecutor URL http://127.0.0.1:5000/api/enroll def hit(i): # 每个线程用不同学号模拟真实抢课 payload {student_no: fS{i:05d}, section_id: 1} try: r requests.post(URL, jsonpayload, timeout5) return r.json().get(code) except Exception: return timeout with ThreadPoolExecutor(max_workers200) as pool: results list(pool.map(hit, range(200))) from collections import Counter print(Counter(results)) # 期望成功数 容量其余为 409跑完看结果如果成功数超过容量说明有超卖回去检查锁如果大量 timeout说明数据库连接池或锁等待超时要调innodb_lock_wait_timeout和连接池大小。这个脚本改改section_id和并发数就能复用到不同场景。5. 避坑与排查选课系统上线前必须过的五道坎前面讲的是「怎么做对」这一章讲「哪里会错」。下面五条都是我在实际项目里踩过或见别人踩过的按「现象 → 原因 → 解决」写清楚。坑一余量显示对不上。现象是页面显示还剩 5 个名额点进去却提示已满。原因是余量字段和选课记录表不一致可能是某次扣减成功但写记录失败没回滚。解决是加一个对账脚本定期用enrollment的 count 去校正course_section.selected并检查所有写操作是否都在事务内。坑二同一学生选上两门冲突课。现象是学生课表出现时间重叠。原因是冲突校验和选课写入之间有并发窗口两个请求同时通过校验。解决是把冲突校验放进FOR UPDATE锁内或者对student_no加一层分布式锁保证同一学生的选课串行化。坑三退课把余量减成负数。现象是selected出现负值。原因是退课接口没判断记录状态重复退课重复减。解决是UPDATE enrollment SET status2 WHERE status1加rowcount判断且扣减 SQL 带selected 0条件。坑四选课高峰数据库连接耗尽。现象是大量请求报连接超时。原因是每个请求都新建连接没复用。解决是用连接池如 DBUtils 或 SQLAlchemy 的 pool池大小按最大并发 / 单请求持有时长估算一般 20-50 够中小系统用。坑五时间冲突判断漏掉「包含」情况。现象是 1-4 节的课和 2-3 节的课被判为不冲突。原因是重叠条件写成了A.start B.start AND A.end B.end。解决是改成A.start B.end AND A.end B.start两个方向都要覆盖。注意这五条里坑一和坑四最隐蔽因为它们不报错只是数据慢慢烂掉或性能慢慢劣化等发现时往往已经积累了大量脏数据。6. 从能跑到好用选课系统的进阶技巧一套能跑通的选课系统只是起点真正拉开差距的是「好用」——候补队列、选课开关、数据导出这些细节。这一章讲几个投入产出比高的进阶点都是我实际项目里验证过值得做的。先说候补队列。热门课满了之后与其让学生反复刷新不如做个候补课程满时把学生加入候补表有人退课时按候补顺序自动补位。实现上建一张waitlist表字段和enrollment类似加一个position排序。退课接口里触发一次「查候补 → 补位 → 通知」的逻辑。补位同样要放在事务里避免补位时又被别人抢走。-- 候补表按加入时间排序先到先得 CREATE TABLE waitlist ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL, section_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_wait (student_no, section_id), KEY idx_section_time (section_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;退课时补位的核心 SQL 是「取该开课候补队列里最早的一条」用ORDER BY created_at LIMIT 1然后走一遍和正常选课一样的扣减和写入流程。这里有个细节补位也要校验时间冲突因为候补期间学生可能已经选了别的课直接补位会造成冲突。所以补位逻辑不能图省事得复用选课的校验函数。再说选课开关。选课不是全天开放的通常有明确的时间窗口。与其在代码里硬编码时间判断不如建一张config表存enroll_start和enroll_end接口入口统一读配置判断。这样运营改时间不用重新发版改条数据就行。配置表还能存每学期的最大选课学分、单日选课上限等规则扩展性好。def check_enroll_window(cur): cur.execute(SELECT cfg_value FROM config WHERE cfg_keyenroll_start) start cur.fetchone()[cfg_value] cur.execute(SELECT cfg_value FROM config WHERE cfg_keyenroll_end) end cur.fetchone()[cfg_value] now datetime.now().strftime(%Y-%m-%d %H:%M:%S) if not (start now end): raise BizError(当前不在选课时间窗口内)最后说数据导出。教务老师最常要的是「某门课选了哪些学生」和「某学生选了哪些课」用一条 JOIN 查询导出 CSV 即可。导出接口要限流别让它拖垮主库常见做法是走只读从库或加缓存。-- 导出某开课的学生名单 SELECT s.student_no, s.name, s.major FROM enrollment e JOIN student s ON e.student_no s.student_no WHERE e.section_id ? AND e.status 1 ORDER BY s.student_no;这几个进阶点里候补队列的收益最大因为它直接减少了高峰期的无效刷新请求等于变相给系统减压。我一般会先上候补和选课开关再考虑更复杂的推荐、抢课提醒之类。做了几套选课系统下来我最大的习惯是任何涉及余量增减的操作先问自己「这条 SQL 在并发下会不会算错」想不清楚就加锁或加条件宁可慢一点也别让数据烂掉。数据一旦错了排查成本远高于当初加一行FOR UPDATE。希望帮到你。本文还有配套的精品资源点击获取