企业官网建设流程全解析

简介：完整版数据库毕业课程设计报告，以学生选课管理系统为实战项目，面向高校计算机、软件工程、信息管理等专业学生及需要完成同类课设的开发者。报告从系统概括、项目背景展开，依次完成需求分析、概念结构与逻辑结构设计，并给出SQL Server 2005数据库建库方案与Visual Studio 2008前台页面实现思路，覆盖学生选课、教师录入与查询成绩、管理员维护学生/教师/课程信息等完整功能链路。资源包共1个文件，格式为docx，整体大小约1.31MB，内部章节组织清晰，便于对照修改和按模板复用。通过研读报告，可以系统掌握数据库E-R图绘制、关系模式转换、前后端联调等核心技能，适用于课程设计文档仿写、答辩准备与毕业设计理论梳理。目前已有838人学习下载，积累了一定的参考价值。

1. 学生选课管理系统：这不是一篇Word文档，而是一套要跑通的数据库工程

每到课程设计验收季节，总有人拿着“（完整版）数据库毕业课程设计学生选课管理系统.docx”这种文件名来问我要“全套代码”。我的回答通常和文件名相反：真正让你拿分的，不是文档里复制来的截图，而是你能独立讲清楚学生、课程、教师、选课四张表怎么设计，选课和退课怎么保证不超员，成绩怎么落库。这套学生选课管理系统，本质上是一次把数据库原理课上的ER图、范式、事务、并发锁全部串起来的综合训练。下面我按实际带课设的顺序展开：先建模，再写脚本，最后排坑和准备答辩。

2. 从需求到关系模型：选课系统的表结构与E-R图怎么定

2.1 先把业务规则写成人话：哪些关系能发生，哪些要拦住

做数据库设计最忌讳一上来就建表。常见翻车是把“学生选课”做成一个大宽表，把学生、班级、专业、课程、教师、成绩全塞在一行里，最后范式检查全不过，数据也大量重复。我一般让学生先写业务规则，规则不超过五条：

• 一个学生可以选多门课，一门课可以被多个学生选，学生和课程之间是多对多关系。
• 多对多关系必须拆成中间表，也就是选课表；选课表上最核心的属性是成绩。
• 同一学生同一门课只能有一条有效选课记录，不能重复选。
• 课程有人数容量，已选人数不能超过容量。
• 只有存在选课记录才能录入成绩；退课之后成绩要跟着清理或置为无效。

这几句话看起来很普通，但每一条最后都会落成一个约束或一段事务逻辑。前两条对应2.2节拆出的关系模式，第三条落成选课表上的唯一键，第四条要靠选课事务里的锁和容量校验，第五条则落到外键和成绩录入存储过程的判断条件。很多网上下载的模板喜欢把规则复杂化：又是用户表、又是角色表、又是权限表。一个课程设计如果做到四张核心表还讲不清，加再多的表也只是给自己挖坑。

E-R图就是顺着这些规则画的。学生、教师、课程是三个实体，教师和课程是一对多，学生和课程是多对多，选课作为联系类型要画成菱形，旁边挂上成绩、选课时间。注意这里有个容易混淆的点：课程表里放teacher_id，表示“谁教这门课”，这是课程自身的属性，不属于选课联系。如果把teacher_id放进选课表，就会出现一门课可由多个教师授课时大面积冗余；除非你的系统要求每次选课都指定教师，否则不要这样设计。

2.2 把E-R图转成关系模式：四张表的字段设计到底怎么定

按上面的规则，我得到四张表的关系模式，这是后续所有SQL脚本的底稿：

• student(student_id, student_name, gender, major, class_name, enroll_year, phone)
• teacher(teacher_id, teacher_name, title, department, phone)
• course(course_id, course_name, teacher_id, credit, hours, capacity, selected_count, semester)
• elective(elective_id, student_id, course_id, grade, elective_time, status)

其中带下划线的是主键，带星号的是外键。elective表是联系表转来的，student_id和course_id是外键，同时联合起来要加唯一键；grade是选课联系上的属性，所以放在选课表里而不是单独建一张成绩表。很多同学会额外建score(student_id, course_id, grade)，这个设计不是不行，但会带来一个尴尬问题：成绩表允不允许出现“没选课就录入成绩”？如果允许，那选课表的存在意义就被削弱了；如果不允许，你又得多做一层触发器去校验。把grade放进elective表，问题自然消失。

为什么课程表里要冗余一个selected_count已选人数？这不是坏冗余，而是为了让选课事务能原子地扣减名额。如果没有这个字段，每次选课前都去COUNT(elective)再比较capacity，在并发下很容易超卖；有了它，可以用一条UPDATE course SET selected_count = selected_count + 1 WHERE course_id = ? AND selected_count < capacity完成校验。这种带业务含义的冗余，在选课系统里是常见做法，后面避坑章会重点展开。

字段类型大致规划如下。

这张表就是你的数据字典初稿。课程设计报告里通常要求写数据字典，你直接在Word文档里把它扩展成字段级表格就行。但更重要的是：别让表结构里的字段和后面写的SQL对不上，我见过太多人报告里是一种结构，数据库里是另一种结构，答辩现场一执行就露馅。

2.3 关系模式检查：满足到第几范式才算合格

课程设计答辩时老师一定会问：你这张表到第几范式？我的标准是做到3NF。student表里所有非主属性都完全依赖student_id，不存在部分依赖；course表里course_name、capacity都由course_id决定，teacher_name虽然能由teacher_id决定，但我们没有把teacher_name放进course表，所以不存在传递依赖。elective表的成绩、选课时间完全依赖elective_id，student_id和course_id只是外键，决定成绩的是整条选课记录。整体满足3NF。

要特别注意一个反例：有人会把“班级”和“专业”合并到一个字段，或者在student表里放班主任姓名。前者会因为班级能推出专业，造成更新异常；后者会让非主属性依赖非主属性，属于典型的传递依赖，答辩时被问到“这里是不是重复存储了”很难解释。设计阶段宁可多花20分钟检查依赖，也不要等写完全部SQL后返工。

从E-R图转成表还有一个通用口诀：实体变表，属性变列，联系变外键。如果联系本身有属性，就把联系单独建成一张表。选课的“成绩”就是联系属性，所以elective表必须存在。记住这句话，即使遇到图书馆管理系统、宿舍管理系统，你也能套用。

后续我会以MySQL 8.x为例写DDL；如果你学校指定的是SQL Server，只需要把AUTO_INCREMENT改成IDENTITY、把ENUM改成CHECK约束，表的骨架完全一样。

3. 用MySQL把库建出来：DDL脚本、字符集与初始化数据

3.1 建库建表：为什么选InnoDB而不是MyISAM

写建表脚本之前，先把存储引擎和字符集定下来。学生选课系统有选课事务、有外键约束、有并发写入，这三件事直接否决了MyISAM：MyISAM不支持事务，外键约束虽然能建出来但不生效，表锁会让选课高峰期互相等待。InnoDB提供行级锁和事务，才撑得住第4章的存储过程。

字符集我固定用utf8mb4，而不是utf8。utf8在MySQL里最多存3个字节，遇到生僻字、表情符号会报“Incorrect string value”，而utf8mb4完全兼容。排序规则选utf8mb4_unicode_ci还是utf8mb4_general_ci？功能上差别不大，课程设计选前者更正规。下面是完整DDL，为了反复调试方便，我在最前面加了DROP DATABASE，如果你是在已有库上做，请把这两行去掉。

-- 方便反复调脚本，正式环境请谨慎执行 DROP DATABASE IF EXISTS student_course; CREATE DATABASE student_course DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci; USE student_course; CREATE TABLE student ( student_id CHAR(9) NOT NULL COMMENT '学号', student_name VARCHAR(20) NOT NULL COMMENT '姓名', gender ENUM('男','女') DEFAULT '男' COMMENT '性别', major VARCHAR(50) DEFAULT NULL COMMENT '专业', class_name VARCHAR(30) DEFAULT NULL COMMENT '班级', enroll_year YEAR DEFAULT NULL COMMENT '入学年份', phone VARCHAR(11) DEFAULT NULL COMMENT '手机号', PRIMARY KEY (student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表'; CREATE TABLE teacher ( teacher_id CHAR(6) NOT NULL COMMENT '教师工号', teacher_name VARCHAR(20) NOT NULL COMMENT '姓名', title VARCHAR(20) DEFAULT '讲师' COMMENT '职称', department VARCHAR(50) DEFAULT NULL COMMENT '院系', phone VARCHAR(11) DEFAULT NULL COMMENT '手机号', PRIMARY KEY (teacher_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教师表'; CREATE TABLE course ( course_id CHAR(8) NOT NULL COMMENT '课程编号', course_name VARCHAR(50) NOT NULL COMMENT '课程名称', teacher_id CHAR(6) NOT NULL COMMENT '授课教师工号', credit DECIMAL(3,1) DEFAULT 2.0 COMMENT '学分', hours INT UNSIGNED DEFAULT 32 COMMENT '学时', capacity INT UNSIGNED DEFAULT 60 COMMENT '容量', selected_count INT UNSIGNED DEFAULT 0 COMMENT '已选人数', semester VARCHAR(20) DEFAULT '2025-2026-1' COMMENT '开课学期', PRIMARY KEY (course_id), KEY idx_course_teacher (teacher_id), CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表'; CREATE TABLE elective ( elective_id INT UNSIGNED AUTO_INCREMENT COMMENT '选课流水号', student_id CHAR(9) NOT NULL COMMENT '学号', course_id CHAR(8) NOT NULL COMMENT '课程编号', grade DECIMAL(5,2) DEFAULT NULL COMMENT '成绩', elective_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '选课时间', status TINYINT DEFAULT 1 COMMENT '1有效，0退课', PRIMARY KEY (elective_id), UNIQUE KEY uk_student_course (student_id, course_id), KEY idx_elective_course (course_id), CONSTRAINT fk_elective_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_elective_course FOREIGN KEY (course_id) REFERENCES course(course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课记录表';

这段脚本里几个参数需要按实际场景调整。学号用CHAR(9)是因为很多高校学号固定9位，固定长度用CHAR比VARCHAR少存一个长度字节；如果你学校学号长度不统一，用VARCHAR(20)更稳。phone用VARCHAR(11)而不用BIGINT，是因为手机号不做算术运算，而且未来真出现国际号段时不会崩。course表DECIMAL(3,1)最多能存99.9学分，实际课程最多5.0，留了余量。elective表保留status字段，默认1表示有效选课，退课可以不做物理删除，而是把status置0，这样成绩和选课历史都能留下来。

这里外键名一定要写清楚：fk_elective_student、fk_course_teacher。后面报错时，MySQL会直接抛外键约束名，你一眼就能定位是哪张表的关系出问题。如果不命名，MySQL自动生成的fk_1、fk_2在排查时非常难受。外键还有一个隐藏作用：强制让数据库负担引用完整性。课程设计里你要能说清“为什么不用应用层检查”，原因只有一个——两台机器、两个进程同时操作数据库时，应用层检查一定会有窗口期，数据库约束才是最后一堵墙。

3.2 初始化数据：先插主表再插子表，顺序不能乱

建表完成立刻插数据，唯一要注意的是外键顺序。必须先插teacher，再插course，最后插elective；否则外键校验直接报1452错误。下面是一组能撑起演示的数据：

INSERT INTO teacher (teacher_id, teacher_name, title, department) VALUES ('T00001', '张建国', '副教授', '计算机学院'), ('T00002', '李慧', '讲师', '数学学院'), ('T00003', '王伟', '教授', '计算机学院'); INSERT INTO student (student_id, student_name, gender, major, class_name, enroll_year, phone) VALUES ('202300101', '陈晨', '男', '软件工程', '软工2301班', 2023, '13800001111'), ('202300102', '林晓', '女', '软件工程', '软工2301班', 2023, '13800002222'), ('202300201', '赵磊', '男', '计算机科学', '计科2301班', 2023, '13800003333'), ('202300202', '周雨桐', '女', '计算机科学', '计科2301班', 2023, '13800004444'), ('202300301', '吴迪', '男', '数据科学', '数科2301班', 2023, '13800005555'); INSERT INTO course (course_id, course_name, teacher_id, credit, hours, capacity, semester) VALUES ('CS100001', '数据库原理', 'T00001', 3.5, 48, 60, '2025-2026-1'), ('CS100002', '操作系统', 'T00003', 4.0, 64, 60, '2025-2026-1'), ('MA100001', '离散数学', 'T00002', 3.0, 48, 80, '2025-2026-1'); INSERT INTO elective (student_id, course_id, grade, status) VALUES ('202300101', 'CS100001', 88.5, 1), ('202300101', 'MA100001', NULL, 1), ('202300102', 'CS100001', NULL, 1);

注意我故意让CS100001的已选人数和elective记录不一致：course表里selected_count默认是0，是测试数据，实际运行选课存储过程后才会同步。如果你想让课设演示一开始就好看，可以补一句UPDATE course SET selected_count=2 WHERE course_id='CS100001'，但我建议不要手改，留着后面用存储过程选课，演示时反而更有过程感。

这套初始化脚本不是一个幂等脚本，重复执行会主键冲突。如果你要反复调DDL，我一般把整个建库脚本前面放上DROP DATABASE IF EXISTS再重跑。千万别在已经插了数据的库上直接重跑CREATE TABLE，那才是真正的翻车现场。

3.3 如果学校指定SQL Server：四个必须改的语法差异

很多学校的数据库课程设计还停留在SQL Server 2019。表结构不用变，但DDL里有四处要改：AUTO_INCREMENT要改成IDENTITY(1,1)；ENUM('男','女')要改成CHECK(gender IN ('男','女'))；MySQL的DEFAULT CURRENT_TIMESTAMP在SQL Server里要写成DEFAULT GETDATE()；YEAR类型SQL Server里没有，直接改成INT。外键、唯一键、主键的写法基本通用。另外，SQL Server的存储过程里没有SIGNAL语句，报错可以用RAISERROR('消息', 16, 1)，事务控制仍然是BEGIN TRANSACTION / COMMIT / ROLLBACK。

为什么我依然建议你优先用MySQL？因为MySQL在Windows和Linux上都能装，答辩时老师电脑上可能没有SQL Server，但很常见的是有一个MySQL命令行或DBeaver。数据库课设的重点在“设计”而不是“某个数据库的独占特性”，选一个移植性最好的实现，能省掉很多环境折腾。

4. 增删改查落地：选课、退课、成绩录入的存储过程与事务

4.1 用存储过程还是裸SQL？事务边界是第一选择理由

学生选课管理的核心增删改查并不复杂，但选课和退课是典型的多步写操作，不能用三条裸SQL在应用层拼。以选课为例，先查是否重复、再查容量、再INSERT、再UPDATE已选人数，这四步只要中间任何一步失败，前面成功的操作就必须撤销。应用层做事务不是不行，但边界容易漏：一次请求里可能既有查又有写，连接一断事务就悬空了。把整个流程封装进存储过程，由数据库统一保证原子性，课设答辩时也能讲清“为什么用存储过程”，而不是一句“老师要求用”。

另外，存储过程在生产环境未必是首选，但课程设计场景非常合适：批改速度快、依赖少、一个脚本就复现业务逻辑。下面选课存储过程我加了注释，参数只有学号和课程号两个输入，错误情况用SIGNAL抛给调用方。

DROP PROCEDURE IF EXISTS sp_enroll_course; DELIMITER $$ CREATE PROCEDURE sp_enroll_course( IN p_student_id CHAR(9), IN p_course_id CHAR(8) ) BEGIN DECLARE v_capacity INT UNSIGNED DEFAULT NULL; DECLARE v_selected INT UNSIGNED DEFAULT NULL; DECLARE v_count INT UNSIGNED DEFAULT 0; START TRANSACTION; -- 锁定课程行，防止其他事务同时改容量或已选人数 SELECT capacity, selected_count INTO v_capacity, v_selected FROM course WHERE course_id = p_course_id FOR UPDATE; -- 课程不存在时，v_capacity 仍为 NULL IF v_capacity IS NULL THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '课程不存在'; END IF; -- 检查是否已经选过这门课 SELECT COUNT(*) INTO v_count FROM elective WHERE student_id = p_student_id AND course_id = p_course_id AND status = 1; IF v_count > 0 THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '该学生已选择这门课程'; END IF; -- 检查剩余名额 IF v_selected >= v_capacity THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '课程名额已满'; END IF; -- 写入选课记录，更新已选人数 INSERT INTO elective (student_id, course_id, elective_time, status) VALUES (p_student_id, p_course_id, NOW(), 1); UPDATE course SET selected_count = selected_count + 1 WHERE course_id = p_course_id; COMMIT; END$$ DELIMITER ;

这段代码最关键的是SELECT ... FOR UPDATE。MySQL默认隔离级别是REPEATABLE READ，普通SELECT是非锁定读，两个事务可以同时读到相同的剩余名额，然后都插入成功，最终超员。加了FOR UPDATE后，事务A拿到course行的写锁，事务B的同一行SELECT FOR UPDATE会等A提交后才继续，从根上避免超卖。

参数说明：p_student_id和p_course_id要和建表时的字符类型严格对齐，CHAR(9)如果多出一个空格，WHERE就匹配不到。应用层传参时最好先TRIM。SIGNAL是MySQL 5.5以后的报错机制，消息文本会直接抛给调用方，比返回-1直观。还要注意，INSERT和UPDATE都在同一个事务里，任何一步失败都会整体回滚，这也是存储过程最重要的存在意义。

4.2 退课流程：先删选课记录还是先减人数

退课和选课方向相反，但事务边界同样重要。下面的sp_drop_course先删除有效选课记录，再根据ROW_COUNT判断有没有删到东西，最后更新课程人数。

DROP PROCEDURE IF EXISTS sp_drop_course; DELIMITER $$ CREATE PROCEDURE sp_drop_course( IN p_student_id CHAR(9), IN p_course_id CHAR(8) ) BEGIN START TRANSACTION; -- 先锁定课程行，保持和选课一致的加锁顺序 SELECT course_id FROM course WHERE course_id = p_course_id FOR UPDATE; DELETE FROM elective WHERE student_id = p_student_id AND course_id = p_course_id AND status = 1; IF ROW_COUNT() = 0 THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '没有找到有效选课记录'; END IF; UPDATE course SET selected_count = selected_count - 1 WHERE course_id = p_course_id; COMMIT; END$$ DELIMITER ;

这里我比选课多做了一个动作：先对course行加FOR UPDATE锁。为什么？为了和选课的加锁顺序保持一致，避免死锁。MySQL里死锁的常见成因就是两个事务以不同顺序加锁：选课先锁course再锁elective，退课如果先删elective再锁course，那另一头的反向操作就可能互相等待。

另一个隐藏决策是物理删除还是逻辑删除。现在这个版本是物理删除，delete以后再也没办法恢复成绩。如果你的课程设计要求保留选课历史，就把DELETE换成UPDATE elective SET status=0 WHERE ...，然后把成绩字段一并置空或保留，并在第4.3节的成绩录入里加status=1条件。两种方案都可以，但你必须在答辩时讲清为什么选其中一种。我建议主演示用物理删除，把“逻辑删除”作为扩展点写进报告，显得你考虑过更完整的设计。

4.3 成绩录入：更新选课记录而不是单独加表

成绩录入是最简单的UPDATE，但很多人会在这里翻车：要么不判断有没有选课，要么把成绩存成冗余字段。我的建议是直接用下面的存储过程。

DROP PROCEDURE IF EXISTS sp_input_grade; DELIMITER $$ CREATE PROCEDURE sp_input_grade( IN p_student_id CHAR(9), IN p_course_id CHAR(8), IN p_grade DECIMAL(5,2) ) BEGIN UPDATE elective SET grade = p_grade WHERE student_id = p_student_id AND course_id = p_course_id AND status = 1; IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '该学生没有选这门课，无法录入成绩'; END IF; END$$ DELIMITER ;

成绩类型用DECIMAL(5,2)，最大999.99，足够表示百分制或五分制。为什么不用INT？成绩可能有0.5分；为什么不直接用FLOAT？浮点存储到数据库后做排序和比较会有精度噪声，DECIMAL是精确定点数，课设里尽量别给自己留这种说不清的坑。

ROW_COUNT这里有一个特性：如果你把成绩从88.5改成88.5，MySQL默认没改行，可能返回0，导致误报“没选课”。所以录入成绩前应用层最好判断“新成绩是否等于旧成绩”，或者先SELECT再UPDATE。这是我在测试阶段真实碰过的玄学问题，记进你的踩坑笔记里。

4.4 查询层：把答辩要用的“数据说话”做成视图

增删改查中的“查”在课设里往往只是SELECT *，这不够。答辩老师通常会问：这个系统怎么看出哪些课选满了？哪些老师课多？下面两个视图基本够用。

CREATE VIEW v_course_selection AS SELECT c.course_id, c.course_name, t.teacher_name, c.capacity, c.selected_count, COUNT(e.elective_id) AS actual_selected FROM course c JOIN teacher t ON c.teacher_id = t.teacher_id LEFT JOIN elective e ON c.course_id = e.course_id AND e.status = 1 GROUP BY c.course_id, c.course_name, t.teacher_name, c.capacity, c.selected_count; CREATE VIEW v_grade_report AS SELECT s.student_id, s.student_name, c.course_name, e.grade, e.elective_time FROM elective e JOIN student s ON e.student_id = s.student_id JOIN course c ON e.course_id = c.course_id WHERE e.status = 1 AND e.grade IS NOT NULL;

视图的优点是把复杂JOIN包装成一个“表”，业务层查询只写SELECT * FROM v_course_selection WHERE capacity = selected_count即可。但注意GROUP BY时，MySQL的ONLY_FULL_GROUP_BY模式要求SELECT列全部出现在GROUP BY里，我上面已经把所有列都写了，省得报错。actual_selected和selected_count的含义要区分：一个来自COUNT，一个来自冗余字段；当数据一致时它们相等，这也是一个不错的数据一致性自检手段。

4.5 应用层调用：Python里怎么正确调用存储过程

课程设计如果只交SQL脚本，老师会要求你做一个简单的控制台或Web页面。以Python为例，连接MySQL时我习惯用PyMySQL。调用存储过程本身很简单，真正重要的是commit放在外面还是里面。我的做法是：存储过程内完成事务，调用层只要保证连接不断、调用后提交即可。

import pymysql conn = pymysql.connect( host="127.0.0.1", user="root", password="123456", database="student_course", charset="utf8mb4" ) try: with conn.cursor() as cur: cur.callproc("sp_enroll_course", ("202300102", "MA100001")) conn.commit() except Exception as exc: conn.rollback() print("选课失败:", exc) finally: conn.close()

注意PyMySQL的callproc会执行存储过程，但存储过程里的SIGNAL异常会以异常形式抛出来，所以try/except必须写。commit在callproc之后执行，因为PyMySQL不会自动提交。如果你在存储过程里已经COMMIT，那么这里的conn.commit()只是落空操作，不会造成影响；但我更推荐把事务放在存储过程内，应用层只做异常处理。这样即使以后换成别的编程语言，业务约束依然在数据库里。

5. 选课系统避坑实录：外键、并发超选和成绩表的五个坑

5.1 外键拦路：删不掉课程不是权限问题，是子表数据没处理

现象：执行DELETE FROM course WHERE course_id='CS100001'，MySQL报错“Cannot delete or update a parent row: a foreign key constraint fails”。

原因：elective表里还有选课记录引用CS100001，外键默认会阻止父表删除。课设里最常出现这个报错的场景是重置数据阶段。

解决：先清理或置无效选课记录，再删课程。如果确实需要级联删除，建外键时用ON DELETE CASCADE，但我不推荐在选课系统里用，因为手滑删课程会把学生成绩单连带删掉。我的做法是：课程表加一个is_active字段，把“下架课程”而不是“删除课程”作为默认动作。这样外键约束永远碰不到边界，数据也安全。

5.2 并发超选：查了剩余名额还是超员，不是SQL写错

现象：两个学生同时提交最后一门课的选课请求，两个事务都先查到剩余名额为1，各自INSERT，最终已选人数变成2，超过容量。

原因：两个事务都用了普通SELECT查remaining，普通SELECT在REPEATABLE READ下是非锁定读，互相看不见对方还没提交的INSERT，自然都认为还有名额。

解决：把“查名额”和“插入选课”放进同一个事务，并且用SELECT ... FOR UPDATE锁课程行，让第二个事务等第一个提交后再判断。或者更极端一点，直接用一条原子UPDATE：UPDATE course SET selected_count = selected_count + 1 WHERE course_id = ? AND selected_count < capacity，然后检查受影响行数。后者适合不需要区分业务错误类型的场景；课设里讲清楚FOR UPDATE方案更稳。

提示：FOR UPDATE锁住的是course表的行，不是整个表。它牺牲了一点并发性能，但换来的是选课人数不会超。课设答辩时如果老师问“性能怎么办”，你可以回答“选课高峰期可以对单门课做限流，或者把容量判断放到应用层缓存，但一致性优先”。

5.3 唯一键没生效：同一个学生同一门课出现两条成绩

现象：elective表里出现了(202300101, CS100001)的两条记录，成绩一好一坏，报表数据对不上。

原因：建表时没有定义UNIQUE KEY，或者业务层“先查后插”时并发重复。也有人把唯一键加在(elective_id, course_id)上，等于没加。

解决：建表脚本里我已经写了UNIQUE KEY uk_student_course (student_id, course_id)，这是硬约束。应用层再查一次是兜底，但绝不能把应用层校验当唯一防线。另外注意，如果退课采用逻辑删除，唯一键会把退课记录和新选课记录冲突起来。遇到这情况，可以把status并入唯一键，例如UNIQUE KEY (student_id, course_id, status)，但status为0的记录要保证只有一条，否则还是冲突。

5.4 死锁：成绩录入和退课互相打架，事务加锁顺序不一致

现象：两个会话同时执行退课和成绩录入，一会死锁报错，一会成绩录到已经退了的课上。

原因：退课存储过程如果先操作elective再操作course，成绩录入如果也操作别的表，两个事务加锁顺序不一致，就可能死锁。另外成绩录入没有检查status，退课刚把status置0，成绩还是被写进去了。

解决：所有涉及elective和course的DML都统一“先锁course行，再操作elective”。成绩录入其实不碰course，那就只操作elective，不做多余加锁。退课时把物理删除换成逻辑删除后，成绩录入还要加上status=1条件，并把成绩字段在退课时一并置空，避免脏数据残留。

5.5 字段长度与严格模式：Incorrect string value不是乱报

现象：插入手机号报“Data too long for column”，插入入学年份报“Incorrect integer value”，WHERE条件明明写了学号却查不到。

原因：手机号字段建成了INT，学号用VARCHAR去匹配CHAR时没有去空格，日期类型插入了格式错误的字符串。MySQL 5.7以后的严格模式会把过长的数据直接报错而不是静默截断，所以很多老教程里的写法现在会翻车。

解决：手机号用VARCHAR(11)，学号用CHAR(9)并保证应用层去空格，日期类型统一用DATE/DATETIME，避免用字符串。如果只是为了显示，入学年份也可以改成YEAR类型，但插入时要确保是四位数字。把这些字段约束写进数据字典，至少能挡住一半低级错误。

6. 从能跑到能答辩：自检脚本、备份和演示数据技巧

6.1 五分钟自检：索引、外键和约束是否都生效

提交前，用下面的SQL把所有约束查一遍，确认不是“看起来建好了”。特别是InnoDB外键，如果建表时漏了ENGINE=InnoDB，外键不会生效，也不会报错。

-- 查看某张表外键、索引、约束 SHOW CREATE TABLE elective; -- 查看所有外键 SELECT table_name, column_name, referenced_table_name FROM information_schema.KEY_COLUMN_USAGE WHERE referenced_table_name IS NOT NULL AND table_schema = 'student_course'; -- 查看已有索引 SHOW INDEX FROM elective;

答辩时老师问“你怎么证明你的事务生效了”，最好的办法是开两个mysql终端，一个执行选课存储过程到一半，另一个查选课表，观察数据看不见未提交内容。你只需要演示一次，这份课设的说服力就上来了。

6.2 备份与演示数据：用mysqldump保底，别把截图当证据

课程设计临近答辩，最怕的事是数据库崩了无法还原。演示前先导出一份完整SQL备份：

mysqldump -u root -p --databases student_course > student_course_backup.sql

还原时执行mysql -u root -p < student_course_backup.sql即可。我吃过一次亏：答辩前夜手滑把elective表DROP了，当时没有备份，只能重新生成演示数据。从那以后我每次都先把备份文件存在另一个目录，再动数据库结构。

演示数据也是有讲究的。不要只用三五个学生，也不要真拿几百人数据把屏幕占满。我一般准备15个学生、5门课，每门课选8-12条记录，成绩有一半为空，再故意让一门课选满名额。演示时先跑一个SELECT * FROM v_course_selection ORDER BY actual_selected DESC，从“哪门课最热”这种问题切入，比直接打开一张空表自然得多。保留成绩为空的数据，是为了当场演示录入成绩功能；留一门满员课程，是为了演示选课报“名额已满”的异常分支。把正常路径和异常路径都走一遍，老师会觉得你真的理解自己写的系统。

最后说一个习惯：每完成一张表或一个存储过程，随手在脚本文件顶部写一行注释说明它演示了什么、调用参数是什么。课设答辩时你不会记得三个月前写的每个细节，但这些注释能帮你在被追问时快速找回上下文。这套从ER图到备份验证的流程，能让你从“下载模板改名字”变成“我能讲清每个表为什么这么设计”，希望帮到你。

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