MySQL触发器中禁止对同表INSERT/UPDATE主键字段，避免主键冲突、外键级联失败及嵌套循环；应使用AUTO_INCREMENT或UUID()生成ID，统一用SQLEXCEPTION捕获错误，并禁用触发器嵌套。
INSERT触发器里直接INSERT同表引发主键冲突
MySQL不允许在AFTER INSERT触发器里对同一张表执行INSERT，否则会报错ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.。但很多人误以为BEFORE INSERT就安全——其实如果在里面手动设了NEW.id为已存在的值，或者用SELECT ... INTO查出一个重复主键再赋给NEW.id，照样触发主键冲突。
实操建议：
- 在
BEFORE INSERT中避免显式赋值NEW.id，尤其不要从SELECT MAX(id)+1这类逻辑取值——并发下必然撞车 - 如需生成唯一ID，优先用
AUTO_INCREMENT或UUID()；若必须自定义，改用INSERT ... ON DUPLICATE KEY UPDATE或应用层重试 - 检查触发器是否隐式调用了含
INSERT的存储过程，MySQL会把整个调用链视为“同一语句上下文”
触发器中UPDATE引发外键级联+主键变更的连锁冲突
当触发器对当前行做UPDATE，且该表有外键指向自身（比如树形结构的parent_id），又恰好把id字段也改了，MySQL会在校验外键时发现原id已被修改、新parent_id找不到对应行，最终抛出ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails——表面是外键错，根因是主键变更打乱了约束检查顺序。
实操建议：
-
BEFORE UPDATE里禁止修改NEW.id，哪怕你确认新值不重复；主键字段一旦定义为PRIMARY KEY，就应视为不可变标识 - 如业务真需要“移动节点”，用软删除+重建路径代替直接改
id和parent_id - 检查
FOREIGN KEY定义是否带ON UPDATE CASCADE，这种级联在触发器内执行时极易失控
触发器嵌套调用导致事务内重复插入
触发器A调用存储过程P，P里又执行INSERT INTO t1，而t1上有触发器B——此时B会再次被激活。如果B里也有类似逻辑，就可能形成循环插入。更隐蔽的是：多个触发器都试图写同一张日志表，而日志表主键依赖NOW()或CONNECTION_ID()，在高并发下时间戳/连接ID重复，直接卡死。
实操建议：
- 用
SELECT @@max_sp_recursion_depth确认是否允许嵌套，生产环境建议设为0（禁用） - 所有触发器内的
INSERT目标表，主键必须是AUTO_INCREMENT或UUID()，禁用FROM_UNIXTIME(UNIX_TIMESTAMP())这类低精度时间字段作主键 - 在触发器开头加
IF @in_trigger THEN LEAVE proc_label; END IF;，配合会话变量做单次入口控制
错误处理没覆盖SQLSTATE导致异常静默
很多人在触发器里用DECLARE EXIT HANDLER FOR SQLSTATE '23000'捕获主键冲突，但MySQL主键冲突实际抛出的是SQLSTATE '23000'下的子类'23000'（通用约束违例）或更具体的'23000'，而SQLSTATE '23000'本身不会被捕获——结果就是错误穿透出去，事务回滚，但开发者以为“已经兜住了”。
实操建议：
- 统一用
DECLARE EXIT HANDLER FOR SQLEXCEPTION，它能捕获所有SQL错误，包括主键、唯一键、外键冲突 - 在HANDLER里加
GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE, @errno = MYSQL_ERRNO;，然后SELECT @sqlstate, @errno;调试时看真实错误码 - 避免在HANDLER里再执行DML操作（比如写错误日志表），否则可能二次触发冲突
真正难处理的不是报错本身，而是触发器执行时没有事务隔离视角——它看到的是“当前语句已生效但事务未提交”的中间态，任何基于SELECT的判断都可能失效。别指望在触发器里做复杂业务决策。
