简介：一套完整的数据库系统原理课程设计报告，以批发企业信息管理系统为实际案例，适合正在完成数据库课程设计的高校学生参考。报告完整梳理了订单、供应商、零售商、商品及商品类型等核心实体的需求分析，给出了概念模型中的E-R图与各实体集码定义，并转换为具体的关系模式，展示了从需求分析、概念结构设计、逻辑结构设计到数据库实施的标准化流程。文档还包含系统主窗口及各表增删改查界面的运行截图，并附有部分基于Java Swing的源程序，便于读者对照学习界面与数据操作的实现思路。资源包内共1个doc文件，压缩包大小约598KB，内容紧凑、结构清晰，可直接作为课程设计报告撰写的模板与参考。目前已有1062人学习浏览，适合需要快速掌握数据库设计流程或形成规范报告的读者使用。
1. 数据库课程设计报告：不是写文档，是造一套能过答辩的系统
数据库系统原理课程设计，很多人把它当成一份三十页的文档来写，结果答辩时老师翻开ER图问一句"这个联系为什么是一对多"，当场就卡壳。这份资源的核心不是给你一篇能抄的报告，而是一整套从需求分析、ER建模、关系模式转换、建表SQL、数据查询实现到答辩陈述的完整链路，让你在五分钟答辩里拿得出能讲清楚的设计，而不是靠截图撑场面。适合正在做数据库课程设计、需要一个能落地复现的完整参考框架的人，也适合想回头把范式、触发器、窗口函数这些底层原理补扎实的从业者。下面直接拆。
2. 需求分析与ER图设计：实体和联系的三个切分点
课程设计报告的第一部分通常是需求分析，但大多数模板只会写"系统需要实现学生管理、课程管理、成绩管理"这种正确的废话。真正的需求分析要落地到两张表上：功能清单和数据字典。
2.1 功能需求与数据需求的拆分写法
我见过不少课程设计报告，需求分析部分抄了一整页"系统可行性分析"，从经济可行到技术可行写了个遍，结果设计数据表的时候发现漏了教师这个实体。需求分析要拆成两个维度写，不能混在一起。
功能需求描述系统要做什么，每条对应一个可验收的操作。拿选课系统举例：学生查看可选课程列表、学生选课和退课、教师录入成绩、按班级统计不及格人数。数据需求描述每个功能背后需要哪些数据支撑。学生选课这个功能背后是选课记录，包含学号、课程号、选课时间、成绩；课程管理背后是课程容量、已选人数、是否开放选课。
写报告时最有效的做法是直接在需求分析章节先放一张数据字典表，声明每张表的存在，后面设计章节再展开字段。这张表同时是ER图设计的依据，避免出现"功能写了一堆，建表时凭空加表"的情况。
| 数据表 | 主要字段 | 服务功能 |
|---|---|---|
| 学生表 | 学号、姓名、班级、入学年份 | 学生管理、登录 |
| 教师表 | 教师号、姓名、职称、所在系 | 教师管理、成绩录入 |
| 课程表 | 课程号、课程名、学分、容量、授课教师号 | 课程查询、选课 |
| 选课表 | 学号、课程号、成绩、选课时间 | 选课、退课、成绩管理 |
写功能需求时要注意业务规则边界。"选课人数已满时禁止选课"属于约束性需求，要单独列出来，因为它后面直接影响触发器和存储过程的设计。课程设计报告里最常见的缺陷就是需求分析只写"管理"两个字，连满员限制、退课截止时间这类业务规则都没有，后面的ER图自然也是空的。
2.2 ER图实体识别：属性和实体别搞混
ER图设计是最容易被老师抓细节的部分，因为它在报告里只占半页，但最能看出你有没有自己做过设计。实体识别有三个常见切分点，切错一个后面全乱。
第一个切分点是属性与实体的边界。班级可以做成学生的属性，也可以做成独立实体。如果班级只有"班级名称"这一个属性，就做成属性；如果班级还有班主任、所属系、入学年份、人数，就必须拆成独立实体，因为学生和班级之间存在"一个班级包含多个学生"的一对多联系。判断标准很简单：这个对象身上有没有多于一个独立属性，并且会不会被其他实体引用。会被引用就拆，不会就留作属性。
第二个切分点是联系属性。选课是学生和课程之间的多对多联系，但成绩挂在选课联系上，不是挂在课程表或学生表上。这是课程设计报告里最容易出错的地方：把成绩做成课程表的字段，导致一门课程只有一条成绩记录。正确做法是把成绩作为联系属性放到选课表里，后面转关系模式时选课表自然成为连接表。
第三个切分点是联系的基数。学生和课程之间是多对多，教师和课程之间是一对多，班级和学生之间是一对多，这些要在ER图上明确标注。常见错误是把所有联系都画成多对多，整张图里全是菱形加连线。一个班级拥有多个学生是一对多，一门课程属于一个系是一对一，基数搞错，后面关系模式转换全跟着错。
ER图画完还要做一件事：数一下实体个数和联系个数。一般课程设计系统至少要有四到五个实体，比如学生、教师、课程、班级、选课记录，联系至少要有四个。如果只画了三个实体，说明需求分析没做透，后面的报告篇幅也撑不起来。
2.3 ER图转关系模式：主外键和连接表
ER图转关系模式有一套固定规则，课程设计报告里把这套规则写清楚，比贴十页SQL更能拿分。
一对多联系在"多"的一方加外键。班级和学生是一对多，学生表加class_id作为外键；教师和课程是一对多，课程表加teacher_id作为外键。多对多联系拆成连接表。学生和课程是多对多，拆成选课表，主键是（student_id, course_id）联合主键，两个字段分别是学生表和课程表的外键。一对一联系在查询频率低的一边加外键，这个场景在课程设计里并不常见，但报告里提一句能体现考虑周全。
转关系模式时还要决定主键。选课表的联合主键（student_id, course_id）能保证一个学生同一门课只有一条记录，这个设计直接写进DDL，后面触发器和存储过程都依赖这个约束。关系模式转换完后，把每张表的主外键关系列成一张表，写进报告设计章节。级联策略这里有个细节：学生表删除时选课表记录要不要一起删？严格来说要设置ON DELETE CASCADE，因为选课记录离开了学生没有意义。但如果你后面要用选课记录做成绩分析，随意级联删除会把历史数据删没。这个矛盾在第5章展开讲，建表时先按最严格的范式来。
3. 建表与规范化：从DDL约束到第三范式的判断标准
ER图转完关系模式，下一步就是写建表SQL。这一步课程设计报告里人人都有，但真正把约束写全、写合理的人不多。建表顺序有个硬性要求：先建被引用的基础表，再建引用外键的业务表，否则外键约束建立会报错。
3.1 DDL建表：约束、引擎与字符集
以选课系统为例，先建教师表和班级表两张基础表，结构从简，只保留后面外键引用的字段。
CREATE TABLE teacher ( teacher_id INT NOT NULL COMMENT '教师编号', teacher_name VARCHAR(50) NOT NULL COMMENT '教师姓名', PRIMARY KEY (teacher_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教师表'; CREATE TABLE class ( class_id INT NOT NULL COMMENT '班级编号', class_name VARCHAR(50) NOT NULL COMMENT '班级名称', PRIMARY KEY (class_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='班级表';逻辑说明：这两张表是基础表，学生表和课程表都要通过外键引用它们的主键。主键都用了INT类型配合自增或者应用层生成，课程设计规模下绰绰有余。
参数说明：ENGINE=InnoDB是事务型引擎的默认选择，支持外键约束和行级锁。CHARSET=utf8mb4保证中文、生僻字和emoji都能正常存入，这个字符集问题第5章会专门讲，建表阶段统一用utf8mb4能省掉后面一半的乱码问题。
接下来是学生表和课程表，这两张表开始出现外键和字段默认值。
CREATE TABLE student ( student_id INT NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL COMMENT '姓名', class_id INT NOT NULL COMMENT '班级编号，外键', enroll_year YEAR NOT NULL COMMENT '入学年份', PRIMARY KEY (student_id), CONSTRAINT fk_student_class FOREIGN KEY (class_id) REFERENCES class(class_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表'; CREATE TABLE course ( course_id INT NOT NULL COMMENT '课程号', course_name VARCHAR(100) NOT NULL COMMENT '课程名', credit DECIMAL(3,1) NOT NULL COMMENT '学分，允许1.5这种小数', capacity INT NOT NULL DEFAULT 60 COMMENT '课程容量', enrolled_count INT NOT NULL DEFAULT 0 COMMENT '已选人数，冗余字段', teacher_id INT NOT NULL COMMENT '授课教师编号', PRIMARY KEY (course_id), CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';逻辑说明：学生表通过class_id外键关联班级表，表示"一个班级有多个学生"。课程表通过teacher_id外键关联教师表，表示"一个教师教授多门课程"。credit用DECIMAL(3,1)而不是FLOAT，因为浮点类型在比较和求和时会出精度问题，成绩统计场景下DECIMAL才是正确选择。
参数说明：enrolled_count是course表上的冗余计数，它违反第三范式，但它是第4章存储过程和第5章反范式设计讨论的核心字段，这里先存在，后面解释为什么会留下它。capacity默认值60，第4章的选课存储过程会拿它做容量判断。UNIQUE约束在课程设计里建议加在业务自然键上，比如课程表如果要求"课程名唯一"，就加UNIQUE KEY uk_course_name。
最后是连接表，也就是选课表，这是整套设计的关键。
CREATE TABLE enrollment ( student_id INT NOT NULL COMMENT '学号', course_id INT NOT NULL COMMENT '课程号', score DECIMAL(5,2) NULL COMMENT '成绩，未录入时为空', enroll_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '选课时间', PRIMARY KEY (student_id, course_id), CONSTRAINT fk_enroll_student FOREIGN KEY (student_id) REFERENCES student(student_id) ON DELETE CASCADE, CONSTRAINT fk_enroll_course FOREIGN KEY (course_id) REFERENCES course(course_id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课记录表';逻辑说明：联合主键（student_id, course_id）从数据层面杜绝了同一个学生重复选同一门课，这是成本最低的防重手段。score字段允许为空，因为选课发生时还没有成绩，是先占位、后录入。enroll_time给定默认值CURRENT_TIMESTAMP，应用层不用手动传时间。
参数说明：两个外键都带ON DELETE CASCADE，删除学生或课程时自动清掉对应的选课记录。这里先按最严格的级联策略来，第5章会分析什么时候不该用CASCADE。COMMENT注释是高性价比细节，老师不需要打开你的运行环境就能看懂字段含义，很多生产环境的建表脚本里这也是强制要求。
3.2 规范化判断：从1NF到3NF的实操检查
规范化是数据库系统原理课程设计的理论核心，报告里不写范式等于白做。但很多人的范式章节只写了定义，没有结合自己的表分析，答辩时一问就露馅。
第一范式要求字段不可再分。学生表的姓名字段如果设计成"姓"和"名"两个字段，在课程设计场景下反而违反第一范式，因为业务上不需要按姓查询或统计，拆了只是增加表宽度。报告里要说明为什么这样切分，而不是机械套定义。
第二范式消除部分函数依赖，这个规则主要针对联合主键表。选课表的主键是（student_id, course_id），如果这张表里存了课程名字段，就会出现问题：课程名只依赖course_id，不依赖student_id，两个学生选同一门课时课程名被重复存储两次，修改课程名要更新多处。这就是部分依赖导致的更新异常。解决办法是拆表，课程名移到课程表，选课表只保留course_id。
第三范式消除传递依赖，主键之外的非主键字段不能相互依赖。假设课程表里有teacher_id和teacher_office两个字段，教师办公室依赖teacher_id，而teacher_id依赖course_id，office通过teacher_id间接依赖course_id，这就是传递依赖。课程表换了授课教师，办公室字段忘记改，数据就不一致。解决办法是把教师办公室移到teacher表。
报告里建议做一张规范化前后对比表，直接展示你做过这个检查过程：
| 检查项 | 违规示例 | 修正方案 | 解决的异常 |
|---|---|---|---|
| 第一范式 | 联系方式字段存多个值 | 拆成多个字段 | 多值字段无法检索 |
| 第二范式 | 选课表存课程名 | 课程名移到课程表 | 冗余导致的更新异常 |
| 第三范式 | 课程表存教师办公室 | 办公室移到教师表 | 修改导致的不一致 |
这张表是报告里性价比最高的一段内容，它把理论课上学到的范式定义和实际建表对上了。答辩老师问"你这个表第几范式"时，你直接打开这张表，从第一范式讲到第三范式，比背概念强得多。
3.3 反范式设计：什么时候故意留冗余
规范化不是越高越好。课程设计报告里如果把所有表都拆到完美第三范式，反而暴露你对实际场景理解不足。
想清楚一个问题：选课人数统计。如果把enrolled_count存到course表里，每次选课、退课都要同步更新这个数字，这是冗余字段，违反第三范式。但每次都实时去查enrollment表统计人数，用COUNT(*)聚合，一个容量60人的课程只需要一条查询，性能完全可以接受，这时候冗余字段就没有意义。
反过来，如果首页要展示每门课程的已选人数占比这种高频统计，每次实时COUNT会让数据库频繁做全表扫描，这时enrolled_count就有了存在价值。取舍标准是：写多读少就严格规范化，读多写少再做冗余。
我在报告里会专门写一小节"反范式设计的取舍"，直接承认course表存在enrolled_count这个冗余字段，然后说明用第4章的存储过程和触发器保证同步更新。这样写比通篇宣称"所有表达到第三范式"更可信。这个字段在第4章的存储过程里更新，在第5章会看到不更新的后果，先挖坑再填坑。
4. 数据操作实现：JOIN、窗口函数与存储过程
第四个章节是课程设计报告的"硬菜"部分，也是答辩时最容易被现场提问的地方。SQL写不出层次，报告写再多也是空架子。
4.1 JOIN查询：三表关联与LEFT JOIN边界
课程设计报告里至少要有一个三表以上的关联查询，否则体现不出对SQL的掌握。以"查询某个班级每个学生的选课情况，包含课程名和授课教师名"为例：
SELECT s.student_name, c.course_name, t.teacher_name FROM enrollment e JOIN student s ON e.student_id = s.student_id JOIN course c ON e.course_id = c.course_id JOIN teacher t ON c.teacher_id = t.teacher_id WHERE s.class_id = 2024001 ORDER BY s.student_name, c.course_name;逻辑说明：enrollment作为连接的核心表，依次关联student、course、teacher三张表，teacher不是直接关联而是通过course表间接关联。WHERE条件过滤出某个班级的学生，ORDER BY排序保证输出稳定。
参数说明：这里全部用INNER JOIN，也就是取四张表的交集。因为选课表里的记录必然同时存在于学生、教师、课程三张表中。如果改成LEFT JOIN，语义就变成"即使学生不存在也把选课记录列出来"，这在当前场景下逻辑不合理。
常被问到的区别是LEFT JOIN的边界。报表场景"统计每个学生的选课数量，没选课的也要显示0"，这时候基表必须是student表，用LEFT JOIN保持学生行不丢失：
SELECT s.student_name, COUNT(e.course_id) AS course_count FROM student s LEFT JOIN enrollment e ON s.student_id = e.student_id GROUP BY s.student_id, s.student_name;逻辑说明：以学生为基准左连接选课表，COUNT统计选课数量，对NULL值不计数，没选课的学生结果自然显示0而不是NULL。GROUP BY把同一个学生的多条选课记录聚合成一行。
参数说明：GROUP BY里同时带上s.student_id和s.student_name，MySQL 5.7以上默认开启only_full_group_by模式，SELECT的非聚合列必须出现在GROUP BY里，否则直接报错。这是答辩现场最常被演示出来的运行时报错，写报告时把GROUP BY字段写全可以省掉一次尴尬。
4.2 窗口函数：排名、累计与占比
窗口函数是数据库课程设计报告拉开档次的地方。普通SQL只能查出成绩，窗口函数在保留原始行的同时算出排名、累计值、占比，是统计类功能的利器。
SELECT c.course_name, s.student_name, e.score, RANK() OVER (PARTITION BY c.course_id ORDER BY e.score DESC) AS rank_in_course FROM enrollment e JOIN course c ON e.course_id = c.course_id JOIN student s ON e.student_id = s.student_id WHERE e.score IS NOT NULL;逻辑说明：RANK()窗口函数在每个课程分区内按成绩降序排名，PARTITION BY指定分区字段，ORDER BY指定排序字段。和GROUP BY的关键区别是：窗口函数不合并行，每一行成绩旁边都带出排名列，原始数据不丢失。
参数说明：RANK()和DENSE_RANK()容易混用。RANK()在成绩并列时跳过名次，比如两个并列第一后下一位是第三名；DENSE_RANK()不跳号，并列第一后下一位是第二名。学校评奖学金按名次发奖用RANK()，按比例划定等级用DENSE_RANK()。报告里把这个区别写清楚，一句话就能让老师知道你不是背模板。
窗口函数还能做累计统计。比如统计每门课程的成绩分布，看多少学生达到某个分数：
SELECT course_id, score, SUM(1) OVER (PARTITION BY course_id ORDER BY score) AS cum_student_count FROM enrollment WHERE score IS NOT NULL;逻辑说明：SUM(1)配合OVER窗口按成绩升序累加，每个分数点上输出当前已累计的学生数，画成绩分布图直接取这两列。这类统计在普通GROUP BY里要写自连接才能实现，窗口函数一行搞定。
这类查询是课程设计报告里创新点的主要素材，大多数模板里根本不会出现窗口函数。你写了，报告的技术含量立刻和抄模板的人拉开差距。
4.3 存储过程与触发器：事务封装与约束兜底
存储过程在课程设计里的最佳落点是把"选课"这个操作封装成完整事务。选课涉及验证学生、验证课程、检查人数、插入记录、更新人数五个步骤，用存储过程包起来，应用层只发一个CALL指令，可维护性明显更好。
DELIMITER $$ CREATE PROCEDURE sp_enroll_course( IN p_student_id INT, IN p_course_id INT ) BEGIN DECLARE v_count INT; DECLARE v_capacity INT; -- 检查学生是否存在 SELECT COUNT(*) INTO v_count FROM student WHERE student_id = p_student_id; IF v_count = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'student not found'; END IF; -- 检查课程是否存在 SELECT COUNT(*) INTO v_count FROM course WHERE course_id = p_course_id; IF v_count = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'course not found'; END IF; -- 检查是否重复选课 SELECT COUNT(*) INTO v_count FROM enrollment WHERE student_id = p_student_id AND course_id = p_course_id; IF v_count > 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'already enrolled'; END IF; -- 检查课程容量 SELECT capacity INTO v_capacity FROM course WHERE course_id = p_course_id; SELECT COUNT(*) INTO v_count FROM enrollment WHERE course_id = p_course_id; IF v_count >= v_capacity THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'course is full'; END IF; -- 插入选课记录 INSERT INTO enrollment (student_id, course_id) VALUES (p_student_id, p_course_id); -- 同步更新课程已选人数 UPDATE course SET enrolled_count = enrolled_count + 1 WHERE course_id = p_course_id; END$$ DELIMITER ;逻辑说明：存储过程依次执行四道校验：学生存在、课程存在、未重复选课、人数未满。SIGNAL语句主动抛出业务错误，应用层能捕获到明确的错误信息，而不是等数据库报一个含糊的外键冲突。最后两步是INSERT加UPDATE，配合事务保证要么都成功要么都失败。
参数说明：p_开头的参数名是输入参数命名约定，用来区分表字段名。如果参数名和字段名重名，比如都叫student_id，SQL语句里的student_id会被解析成参数，导致检索结果永远等于传入值，这是写存储过程最常见的暗坑之一。
事务控制这段还没有真正实现原子性。因为默认配置下每条INSERT和UPDATE都是自动提交的，如果插入成功后UPDATE失败，已选人数就少了。真实项目里应该包上事务控制：
START TRANSACTION; -- 执行上述检查和写入 COMMIT;逻辑说明：START TRANSACTION把后续语句包进一个事务，全部成功才COMMIT，任何一步失败都ROLLBACK回滚，保证enrollment表和course表的已选人数永远一致。报告里建议把有事务和没事务的两个版本都写出来，对比说明为什么需要事务，这是加分写法。
触发器负责在数据库层面做最后一层兜底。比如"课程已满时禁止选课"，也可以直接用触发器实现，不依赖应用层是否正确调用存储过程：
CREATE TRIGGER trg_enrollment_before_insert BEFORE INSERT ON enrollment FOR EACH ROW BEGIN DECLARE v_capacity INT; DECLARE v_count INT; SELECT capacity INTO v_capacity FROM course WHERE course_id = NEW.course_id; SELECT COUNT(*) INTO v_count FROM enrollment WHERE course_id = NEW.course_id; IF v_count >= v_capacity THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'course is full'; END IF; END;逻辑说明：BEFORE INSERT触发器在新行插入前执行，NEW代表即将插入的新记录。触发器与存储过程的区别在于：存储过程需要应用层显式调用，触发器由数据库自动执行。实际项目中两者经常同时使用，存储过程做显式事务控制，触发器做最后防线。
写触发器要注意边界：触发器内不能对本表做INSERT、UPDATE、DELETE操作，否则会递归触发自己。课程设计报告里有人为了省事，在触发器里直接UPDATE同表，一插入就死循环，这是第5章重点讲的一个坑。
5. 避坑排查：课程设计里最容易翻车的五个场景
这部分是前面设计链路里最容易踩的坑，每条都是"现象、原因、解决"三段式，照着排查能省一半调试时间。
5.1 删除学生后选课记录变成孤魂数据
现象：删除一个学生记录后，enrollment表里还残留着这个学生的选课记录，按课程统计选课人数时数据对不上。
原因：建选课表时外键没有加ON DELETE CASCADE，或者干脆没建外键，只靠应用层删数据。应用层删学生时忘了同步删选课记录，就留下了孤儿记录。
解决：选课表的外键设计成ON DELETE CASCADE，删学生自动删选课记录。但如果你的业务需要保留历史成绩做分析，不要用物理删除，而是给学生表加一个is_active状态位，用逻辑删除代替物理删除。这个取舍要在报告里写清楚，说明你理解级联删除的代价和适用边界。
5.2 触发器递归调用死循环
现象：给enrollment表写了一个BEFORE INSERT触发器，往表里插一条记录，触发器内部又去更新enrollment表的一个计数字段，结果插入操作直接卡死或报错。
原因：触发器内对同一张表执行写操作会再次触发自己，形成递归调用。MySQL会检测到递归并直接报错，但在更复杂的场景中表现为插入极慢而不是报错，排查起来更费劲。
解决：触发器的逻辑里只能操作其他表，不能操作自己。要维护course表上的enrolled_count，在enrollment表的触发器里去UPDATE course表，而不是UPDATE enrollment表。这条边界写成报告后，老师会认可你对触发器理解到位。
注意：写任何触发器之前，先看一眼它写在哪个表上，凡是出现了对同一张表的写操作，停下来重新设计。
5.3 中文乱码和特殊字符插入失败
现象：插入一条课程名称带特殊符号的记录，数据库报字符集错误，或者查询出来的中文全是问号。
原因：建表时用了utf8而不是utf8mb4，utf8字符集无法完整存储四字节的emoji和冷僻字。另一个原因是连接串里没有指定字符集参数，客户端和服务端字符集不一致。
解决：统一字符集方案。建表SQL全部写成DEFAULT CHARSET=utf8mb4，连接串统一加characterEncoding=UTF-8。排查时用SHOW CREATE TABLE确认表字符集，用SHOW VARIABLES LIKE 'character_set%'检查服务端和客户端配置。这个问题不难，但答辩现场最容易当场演示翻车。
5.4 索引没生效导致查询越来越慢
现象：选课表的联合主键（student_id, course_id）建好了，但按course_id单独查某课程的所有选课记录时依然走全表扫描，数据量一大就卡。
原因：联合索引遵循最左前缀原则，索引字段顺序是student_id在前、course_id在后，单独按course_id查询用不上这个联合索引，除非额外给course_id单独建索引。
解决：给course_id单独建辅助索引。这时的取舍是：联合主键保证同一个学生不能重复选同一门课，主键顺序不能改；但高频查询"某课程所有选课学生"确实需要单列索引支撑。一条语句就能建好：
CREATE INDEX idx_enrollment_course ON enrollment(course_id);逻辑说明：这条索引不影响联合主键的唯一性约束，只负责加速按course_id的检索。建完后用EXPLAIN SELECT看执行计划，type列从ALL变成ref，说明索引生效了。报告里放一个EXPLAIN结果截图，是很实在的亮点。
5.5 报告文档与建表脚本对不上
现象：答辩时老师翻开报告里的数据字典，指着enrollment表说这里应该有成绩字段，再打开你的建表脚本，发现成绩字段实际在另一张表上。
原因：报告先写完，代码后写完，中间改过表结构没有回头同步文档，两边各说各话。
解决：把建表脚本当作唯一事实来源。报告写完以后跑一遍SHOW CREATE TABLE，对照实际的表结构逐字段改文档。课程设计报告的最优顺序是先写代码后写文档，文档永远比代码晚一天定稿。这条是最容易被忽视的坑，也是答辩翻车的头号原因。
6. 答辩前自查：把报告文档与建表脚本对齐的三个动作
课程设计答辩一般只有五到八分钟，老师没有时间通读三十页报告，他只会做三件事：翻数据字典、看ER图、问一条SQL。所以最后的自查就围绕这三件事展开。
第一个动作是把ER图、数据字典、建表脚本三份文件并排打开，逐表核对实体、字段、主外键关系。ER图上画的联系数量必须与建表脚本里的外键数量一致，ER图上有几条连线，建表语句里就该有几个外键约束。这个动作不需要动脑子，五分钟查完，但能让你避免"报告说一对多、代码里没有外键"这种最致命的漏洞。
第二个动作是为报告里每个功能需求准备一条能跑的SQL。需求分析写了"查询某班级学生的选课情况"，就准备好对应的SELECT语句；写了"选课满员时禁止选课"，就准备好触发器或存储过程的调用演示。老师问任何一个功能点，你都能现场执行出结果，这比背十页概念有用得多。准备时不只看正确结果，还要想清楚这条SQL用到哪些表、为什么这样写，因为老师大概率会追问一行代码的逻辑。
第三个动作是主动准备两个开放性问题：一个是"为什么用存储过程而不用应用层实现"，另一个是"如果选课人数超过容量怎么办"。这两个问题几乎每个答辩老师都会问，因为它们是业务规则和数据库机制的交叉点。四步走答法：先答设计目标，再说触发机制，然后演示代码，最后承认冗余字段带来的同步问题。能主动说出哪里做得不到位，比被问住之后支支吾吾体面得多。
这套流程我每次做课程设计或评审别人的报告都会强制走一遍。最深的教训是：一份报告最大的风险不是技术难点没解决，而是文档和代码各说各话。从那以后我每次都先跑一遍SHOW CREATE TABLE核对结构，再对着报告逐字段改，宁可少写两页分析，也要保住文档与代码的对应关系。希望这套自查流程也能帮你少踩一个坑。
本文还有配套的精品资源，点击获取
