应使用三张表：students、courses和enrollments中间表，通过联合主键与双外键实现多对多关系，并支持扩展字段；查询已完成课程需借助progress表及联合索引；外键必须设置ON DELETE RESTRICT防止脏数据；课程大纲宜用规范化表结构而非JSON字段。
学生表和课程表怎么设计才不会漏关联关系
在线课程平台里，学生和课程不是简单的一对一，得支持「一个学生选多门课」「一门课被多个学生选」，必须用中间表。直接在 students 表里加 course_id 字段，或者反过来在 courses 表里存学生 ID，都会导致数据冗余、更新异常，甚至无法表达退选、重修等真实行为。
正确结构是三张表：
-
students：存学生基础信息，主键id（建议用自增或 UUID） -
courses：存课程元数据，主键id -
enrollments（或叫student_courses）：只有两个字段 ——student_id和course_id，联合主键 + 双外键约束
这样既能查「某学生所有课程」，也能查「某课程所有学生」，还能加 enrolled_at、status（如 'active' / 'dropped'）等扩展字段。
MySQL 中怎么高效查「学生已学完的课程列表」
常见需求是展示学生个人中心里的「已完成课程」，不能只靠 JOIN 就完事。如果课程有章节、视频、测验等进度跟踪，通常会另建 progress 表记录每个学生每门课的完成百分比或最后学习时间。
推荐做法是：在 progress 表中设 student_id、course_id、completion_rate（DECIMAL(5,2)）、updated_at，并建立联合索引：
CREATE INDEX idx_student_course ON progress (student_id, course_id);
查询时避免全表扫描：
SELECT c.title, p.completion_rate FROM courses c JOIN progress p ON c.id = p.course_id WHERE p.student_id = 123 AND p.completion_rate >= 100.0;
注意：completion_rate >= 100.0 比 = 100.0 更安全，因为浮点计算可能有微小误差；若用整数存百分比（如 100 表示 100%），则可用 = 100。
外键没加或加错会导致什么线上问题
很多团队上线前忽略外键约束，结果出现脏数据：比如课程被删除后，enrollments 表里还留着指向已不存在 course_id 的记录，后续 JOIN 查询直接丢行，前端显示「该学生没选任何课」，但其实只是关联断裂。
正确做法是建表时明确声明外键，并指定行为：
- 学生退课：用
DELETE删除enrollments行，不是删courses或students - 课程下架：应设
status字段标记为'archived'，而不是物理删除courses行 - 真要删课程，外键需设
ON DELETE RESTRICT（默认），防止误删；若允许级联清理选课记录，才用ON DELETE CASCADE，但要非常谨慎 —— 一次DROP可能清空几百条学习进度
建外键示例：
ALTER TABLE enrollments ADD CONSTRAINT fk_enrollment_student FOREIGN KEY (student_id) REFERENCES students(id) ON DELETE RESTRICT, ADD CONSTRAINT fk_enrollment_course FOREIGN KEY (course_id) REFERENCES courses(id) ON DELETE RESTRICT;
MySQL 8.0+ 的 JSON 字段适合存课程大纲吗
课程大纲（如章节名、视频时长、作业截止时间）结构相对固定，且常需按章节筛选、排序、统计，用 JSON 类型反而增加复杂度。例如想查「第 3 章包含多少个视频」，就得用 JSON_CONTAINS 或 JSON_EXTRACT，无法走索引，查询变慢。
更稳妥的做法是拆成独立表：
-
chapters：id,course_id,title,order_num -
videos：id,chapter_id,title,duration_sec
这样既能快速查某课程所有章节（WHERE course_id = ? ORDER BY order_num），也能轻松统计每章视频数（GROUP BY chapter_id）。只有当大纲结构高度动态、字段极不统一（比如每门课自定义不同类型的课后任务），才考虑 JSON，但得接受查询能力受限。
