MySQL中一张表对AFTER UPDATE只能定义一个触发器，多个逻辑需合并；可安全更新其他表，但跨表操作须用标量子查询；刷新原表字段应改用BEFORE UPDATE直接赋值NEW。
不能在 AFTER UPDATE 触发器里直接 UPDATE 原表，但可以安全更新其他表；同一张表上最多只能有一个 AFTER UPDATE 触发器，所谓“多个”必须靠逻辑合并或分拆到不同表。
MySQL 不允许一个表有多个同类型触发器
一张表对 AFTER UPDATE 只能定义一个触发器。如果你写了第二个，MySQL 会报错：Can't create trigger 'xxx': same trigger event and action time already exists for this table。这不是版本限制，是 MySQL 的硬性设计——每个 (table, timing, event) 组合唯一。
常见误操作是想为不同字段更新写多个触发器，比如：
- 一个触发器处理
status变更后同步log_table - 另一个处理
user_id变更后更新stats_summary
这必须合并进同一个 AFTER UPDATE 触发器里，用 IF 判断字段变化：
DELIMITER $$
CREATE TRIGGER t1_after_update
AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
IF OLD.status != NEW.status THEN
INSERT INTO order_logs (order_id, event, created_at)
VALUES (NEW.id, CONCAT('status changed to ', NEW.status), NOW());
END IF;
IF OLD.user_id != NEW.user_id THEN
UPDATE user_stats SET order_count = order_count + 1
WHERE user_id = NEW.user_id;
END IF;
END$$
DELIMITER ;
AFTER UPDATE 中跨表更新的写法和限制
你可以在 AFTER UPDATE 触发器里安全地 UPDATE、INSERT 或 DELETE 其他表，但要注意三点：
- 子查询必须返回单值，否则报错
Subquery returns more than 1 row；关联更新务必用标量子查询，别写UPDATE t1 JOIN t2（语法不支持） - 外键约束仍生效，如果目标表有
ON UPDATE CASCADE，它会在触发器执行前/后按事务顺序触发，可能引发意外交互 - 触发器没有独立事务，所有操作和主 SQL 在同一个事务里；一旦触发器内 SQL 报错（如违反唯一键），整个语句回滚
例如：订单完成时更新用户等级，但只在用户当前积分达标时才升：
UPDATE users SET level = level + 1 WHERE id = NEW.user_id AND (SELECT total_points FROM user_points WHERE user_id = NEW.user_id) >= 10000;
注意这里没用 JOIN，而是把条件收进 WHERE 子查询——这是唯一可靠写法。
想“级联更新原表字段”？改用 BEFORE UPDATE
很多人想用触发器自动刷新 updated_at 或维护计数器，却错误地放在 AFTER UPDATE 里去 UPDATE 自己，结果撞上错误 ERROR 1442。
正确做法是换到 BEFORE UPDATE，直接赋值给 NEW：
DELIMITER $$ CREATE TRIGGER orders_before_update BEFORE UPDATE ON orders FOR EACH ROW BEGIN SET NEW.updated_at = NOW(); SET NEW.version = NEW.version + 1; END$$ DELIMITER ;
这种写法不涉及任何 DML，只是修改即将插入/更新的行镜像，完全合法且高效。别试图绕过限制用 INSERT ... SELECT 或临时表模拟——徒增复杂度和锁竞争。
并发与性能容易被忽略的点
触发器逻辑跑在主 SQL 的事务上下文中，意味着：
- 高并发写入时，子查询若没走索引（比如查
user_stats没建user_id索引），会拖慢所有UPDATE orders请求 - 如果触发器里更新了另一张高频读写的表（如
cache_status），可能成为锁瓶颈，甚至引发死锁（尤其当应用层也频繁更新该表时） - 主从复制中，触发器在从库不执行（除非
binlog_format = ROW且显式开启log_bin_trust_function_creators），但多数场景下从库只读，这点影响小
真正难调试的是“看似成功但漏更新”：比如触发器里用了 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，表面没报错，实际因冲突跳过，业务状态就断链了。这类逻辑建议加日志表或移到应用层兜底。
