中间表插入前必须确保主表数据存在，否则触发外键约束错误；推荐先用INSERT IGNORE或ON DUPLICATE KEY UPDATE保证主表记录，再插入中间表；批量关联插入应使用INSERT INTO ... SELECT配合JOIN，避免VALUES多值漏配；更新需区分关系变更（DELETE）与属性变更（UPDATE带联合条件）；ON DUPLICATE KEY UPDATE需谨慎，明确指定更新字段并确认唯一键定义。
中间表插入必须先确保主表数据存在
MySQL不支持“自动级联创建主表记录”，所以往 student_course 这类中间表插入前，student_id 和 course_id 对应的行必须已在 student 和 course 表中存在。否则会触发外键约束错误：Cannot add or update a child row: a foreign key constraint fails。
实操建议：
- 先用
INSERT IGNORE INTO student ...或INSERT ... ON DUPLICATE KEY UPDATE确保学生/课程已存在，再插入中间表 - 若需批量插入并容错，可临时禁用外键检查（仅限开发/导入场景）：
SET FOREIGN_KEY_CHECKS = 0;，操作完立即恢复：SET FOREIGN_KEY_CHECKS = 1; - 避免在应用层拼接 SQL 时把
NULL或空字符串当合法外键值传入——数据库不会帮你转换或提示语义错误
INSERT INTO ... SELECT 是最安全的关联插入方式
当你需要基于已有学生和课程批量生成选课关系（比如给所有新生默认选“导论课”），直接写多值 VALUES 容易漏配或顺序错乱；用 INSERT INTO ... SELECT 能靠 JOIN 逻辑保证两端数据真实可关联。
示例：
INSERT INTO student_course (student_id, course_id) SELECT s.id, c.id FROM student s CROSS JOIN course c WHERE s.grade = '2026' AND c.title = '数据库导论';
注意点：
-
CROSS JOIN在这里是有意为之，但务必加WHERE限制，否则会爆炸式生成笛卡尔积 - 如果目标是“只插入不存在的关系”，加
NOT EXISTS子查询防重复：AND NOT EXISTS (SELECT 1 FROM student_course sc WHERE sc.student_id = s.id AND sc.course_id = c.id) - 该语句不走索引优化时可能慢——确保
student(grade)和course(title)有适当索引
更新中间表字段要区分“关系变更”和“属性变更”
中间表不只是两个外键，常带业务字段如 enroll_time、score、status。更新时容易混淆两类操作：
- “关系变更”：学生退课 → 应该
DELETE FROM student_course WHERE student_id = ? AND course_id = ?，不是把status改成'dropped'（除非业务明确要求留痕） - “属性变更”：更新成绩 →
UPDATE student_course SET score = 89 WHERE student_id = ? AND course_id = ?，此时必须带完整联合条件，避免误更新其他行 - 切忌用
UPDATE student_course SET student_id = ? WHERE course_id = ?这种单边条件——会批量改错人
ON DUPLICATE KEY UPDATE 在中间表上要慎用
中间表通常设 PRIMARY KEY (student_id, course_id)，所以 INSERT ... ON DUPLICATE KEY UPDATE 看似能“存在则更新，不存在则插入”。但它有个隐性陷阱：只要联合主键冲突就触发更新，而你未必想覆盖所有字段。
比如：
INSERT INTO student_course (student_id, course_id, enroll_time, score) VALUES (101, 201, NOW(), NULL) ON DUPLICATE KEY UPDATE enroll_time = VALUES(enroll_time);
问题在于：VALUES(enroll_time) 取的是本次 INSERT 的值，但如果 score 字段本应保留旧值，上面语句并不会动它——这没问题；但如果你漏写了 score = VALUES(score)，而实际想清空成绩，就会出错。
更稳妥的做法：
- 明确知道要更新哪些字段，且逻辑简单 → 可用
ON DUPLICATE KEY UPDATE - 涉及复杂判断（如“仅当当前 status 为 enrolled 才允许更新 score”）→ 改用
INSERT ... SELECT+UNION ALL或事务内先SELECT再INSERT/UPDATE - 永远在执行前确认中间表的主键/唯一键定义——有些团队会加额外唯一索引（如
UNIQUE(course_id, student_id)），导致意外触发 duplicate 分支
INSERT 和 UPDATE 的写法边界。 
