根本原因是after触发器执行时机与mysql外键即时校验冲突，导致子表插入时父表记录尚未通过约束验证；解法是改用before触发器配合uuid预生成主键，确保外键引用从源头合法。
触发器里报 CANNOT ADD OR UPDATE A CHILD ROW: A FOREIGN KEY CONSTRAINT FAILS，根本不是触发器写错了，而是它执行时机撞上了外键校验——MySQL 的外键检查默认在语句结束时立刻触发，而 AFTER INSERT 触发器里的子表插入动作，恰好卡在这个“已检查、未提交”的尴尬窗口里。
为什么 AFTER 触发器总在外键上栽跟头
你写了个 AFTER INSERT ON parent_table，想往 child_table 插一条记录引用 NEW.id，但 MySQL 在主语句执行完、还没提交事务时，就对所有外键约束做了一次强制校验。此时 child_table 新增的那条记录，其 parent_id 指向的 parent_table 行虽已生成，却尚未通过外键合法性验证（比如父表刚插、还没被校验链覆盖），直接报错。
-
AFTER触发器无法改变主语句的约束检查顺序，它只是“事后补刀”，但刀还没落下，锁已经上了 - 哪怕父表和子表都在同一事务里，MySQL 也不保证外键引用在触发器执行时已被认可
- 这种冲突在高并发或带级联操作的表结构中更频繁，因为校验路径变长、窗口更窄
BEFORE 触发器 + UUID() 是 MySQL 下最稳的解法
既然 AFTER 被外键检查卡死，那就把主键值提前准备好，让外键引用从源头就合法。MySQL 不支持 DEFERRABLE，所以必须让 parent_table 的主键在语句执行前就确定且唯一。
- 别用
SELECT MAX(id)+1—— 并发下必然重复，触发主键冲突 - 别依赖
AUTO_INCREMENT后再读LAST_INSERT_ID()——BEFORE里读不到，AFTER里又来不及 - 直接在
BEFORE INSERT中用UUID()或UUID_SHORT()赋值给NEW.id，确保值唯一且可被子表立即引用 - 示例：
CREATE TRIGGER parent_insert_before BEFORE INSERT ON parent_table FOR EACH ROW SET NEW.id = UUID();
之后你在 AFTER INSERT 里插入子表时，NEW.id 已是确定值，外键检查能顺利通过。
SET FOREIGN_KEY_CHECKS = 0 不是修复，是掩耳盗铃
有人试过在触发器开头加 SET FOREIGN_KEY_CHECKS = 0，结果发现语法错误或根本无效——MySQL 明确禁止在触发器内修改这个会话变量。它只允许在客户端连接层面设置，且必须成对出现。
- 触发器里写
SET FOREIGN_KEY_CHECKS = 0会直接报错ERROR 1337 (42000) - 就算你绕过触发器，在应用层先关再开，也只是跳过校验，不解决数据逻辑问题
- 关了之后插入的孤儿记录（子表有值、父表无对应行）不会被自动清理，后续打开开关也无感知
- 真正要查这类脏数据，得手动跑：
SELECT child.id FROM child_table child LEFT JOIN parent_table p ON child.parent_id = p.id WHERE p.id IS NULL;
触发器里写子表前，先 SELECT INTO 预检
如果业务不允许改主键生成方式，又不能接受 UUID，那就在触发器里放弃“硬插”，改用预检+条件分支。这不是兜底，而是把约束冲突从运行时报错，提前到逻辑判断阶段。
- 用
SELECT COUNT(*) INTO @cnt FROM parent_table WHERE id = NEW.id;确认父记录存在 - 再用
IF @cnt > 0 THEN INSERT INTO child_table (...) VALUES (...); END IF;控制是否执行 - 注意：这不能替代外键约束，只是避免触发器因引用不存在而失败；外键本身仍需保留，防止应用直连绕过触发器写入
- 并发安全靠的是外键本身的排他性，不是触发器里的
SELECT—— 所以仍要配合INSERT IGNORE或ON DUPLICATE KEY UPDATE处理极小概率冲突
最易被忽略的一点：所有这些方案都假设你没在触发器里调用存储过程，而那个存储过程又悄悄写了同名子表——MySQL 会把整个调用链视为“同一语句上下文”，照样触发 ERROR 1442。真遇到这种嵌套，得一层层拆出来，用应用层事务控制替代触发器联动。
