触发器可校验多对多中间表但不能修改它；防重等基础约束应优先用联合主键和外键实现，触发器仅处理复杂业务逻辑如选课数量上限。
触发器能校验多对多中间表，但不能直接改中间表本身
MySQL 触发器可以用于校验多对多关联的合法性（比如防止重复插入相同 student_id/course_id 组合），但**不能在触发器里对正在被操作的中间表执行 INSERT/UPDATE/DELETE**——否则立刻触发 ERROR 1442。这是硬性限制，不是写法问题。
常见误操作：在 BEFORE INSERT ON student_course 里又去 SELECT COUNT(*) FROM student_course WHERE ... 做防重判断 → 没问题；但若接着写 INSERT INTO student_course ... 或 UPDATE student_course ... → 直接报错。
- 唯一安全的读操作是单值子查询，例如：
(SELECT 1 FROM student_course WHERE student_id = NEW.student_id AND course_id = NEW.course_id) - 所有写操作（包括
INSERT、UPDATE、DELETE、SELECT ... FOR UPDATE）都禁止出现在同一张表的触发器中 - 视图也不行——哪怕查的是视图，只要底层映射到
student_course，一样触发 1442
跨表校验必须用单值子查询嵌入 IF 或 EXISTS
想在校验时检查学生是否已选某门课，或课程是否已达人数上限，得把逻辑压进子查询，不能拆成两步。
正确写法示例（防重复选课）：
IF EXISTS (SELECT 1 FROM student_course WHERE student_id = NEW.student_id AND course_id = NEW.course_id) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '该学生已选此课程'; END IF;
错误写法（会报错或逻辑失效）：
DECLARE cnt INT DEFAULT 0; SELECT COUNT(*) INTO cnt FROM student_course WHERE student_id = NEW.student_id AND course_id = NEW.course_id; IF cnt > 0 THEN ... -- 这里不报错，但 SELECT ... INTO 在触发器里受限且易出 NULL 问题
-
EXISTS比SELECT ... INTO更安全，不依赖变量声明，也避免多行返回错误 - 子查询必须返回至多一行，否则报
Subquery returns more than 1 row - 注意 NULL：如果
NEW.student_id不存在于students表，子查询结果为NULL，EXISTS返回FALSE，不会误拦；但用=判断时需补IS NULL分支
外键 + 唯一索引比触发器更适合基础一致性保障
多对多中间表的核心约束（如“一个学生不能重复选同一门课”）应该优先靠数据库原生机制实现，而不是触发器。
推荐建表方式：
CREATE TABLE student_course ( student_id INT NOT NULL, course_id INT NOT NULL, PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES students(id) ON DELETE CASCADE, FOREIGN KEY (course_id) REFERENCES courses(id) ON DELETE CASCADE );
- 联合主键
(student_id, course_id)天然防止重复插入，性能远高于触发器里的EXISTS查询 - 外键确保
student_id和course_id必须存在，避免脏数据 - 触发器只用来处理外键管不了的逻辑，比如“每个学生最多选 5 门课”，这时才需要查
COUNT(*)并SIGNAL - 别忘了给
COUNT(*)查询字段加索引——联合主键已覆盖，无需额外索引
批量插入时触发器开销会被线性放大
用 INSERT INTO student_course VALUES (1,1),(1,2),(2,1); 插入 3 行，触发器会执行 3 次，每次跑一遍子查询。如果没索引或子查询复杂，延迟会明显上升。
- 用
EXPLAIN确认校验子查询是否走索引，特别是涉及WHERE条件的字段 - 避免在触发器里调用自定义函数，尤其是那些内部再查表的函数
- 上线前压测：模拟 100 行批量插入，观察单条
INSERT耗时是否从 2ms 涨到 200ms+ - MySQL 8.0.16+ 可考虑用
CHECK约束替代简单逻辑，比如CHECK (student_id > 0 AND course_id > 0)，它比触发器轻量得多
真正难的不是写触发器，而是判断哪部分该由数据库兜底、哪部分该交还应用层——比如“选课总学分不能超 30”这种带聚合计算的规则，放触发器里查全表太重，不如在应用提交前查一次缓存或汇总表。
