MySQL触发器中禁止跨表UPDATE和原表修改，正确做法是BEFORE中仅操作NEW变量，AFTER中跨表更新并加NULL判断与索引优化，且INSERT IGNORE/REPLACE不触发触发器。
不能直接用 UPDATE JOIN 跨表更新，也不能在触发器里 COMMIT 或改原表——否则会报错或数据清空。
BEFORE UPDATE 只能改 NEW，不能碰原表
想在更新主表时顺手改掉冗余字段？别写 UPDATE main_table SET ...，MySQL 5.7+ 明确禁止。一写就报：Can't update table 'main_table' in stored function/trigger because it is already used by statement...。
正确做法是只操作 NEW 变量：
-
SET NEW.updated_at = NOW()—— 合法，影响即将插入/更新的行 -
SET NEW.status = 'synced'—— 合法，覆盖应用层传入值 -
UPDATE related_table SET name = NEW.name WHERE id = NEW.related_id—— 合法，跨表更新
注意：所有对原表的修改必须放在 AFTER 触发器里，且只能通过 NEW 或子查询间接驱动。
AFTER INSERT / UPDATE 才能安全跨表写入
要同步到另一张表（比如 order 表里的 username 字段），必须用 AFTER 触发器，确保主表数据已落盘、自增 ID 可读。
常见错误写法：
UPDATE order SET username = NEW.username WHERE user_id = NEW.id;
这本身合法，但容易踩两个坑：
- 如果
NEW.username是 NULL（字段没被显式更新），整条语句会把原来有效的值设成 NULL —— 必须加判断：IF NOT (NEW.username OLD.username) THEN ... - 高并发下多个连接同时更新同一张
order表，容易引发innodb_row_lock_time_avg突增，锁等待堆积
推荐加一层保护：
IF NOT (NEW.username <=> OLD.username) THEN UPDATE order SET username = COALESCE(NEW.username, OLD.username) WHERE user_id = NEW.id; END IF;
跨表更新必须用标量子查询，不能 JOIN
触发器里不支持 UPDATE t2 JOIN t1 ON ... 语法，会直接报错（错误信息还可能误导成“子查询不支持 LIMIT”）。
正确写法是把关联逻辑收进括号，强制返回单值：
SET NEW.sync_status = ( SELECT IF(t2.is_valid = 1, 'ok', 'error') FROM config t2 WHERE t2.key_name = NEW.config_key LIMIT 1 );
硬性要求：
- 子查询必须带
LIMIT 1，否则多行返回中断整个触发器 - 若查不到匹配行，
NEW.sync_status会是 NULL，得提前用COALESCE(..., 'unknown')设默认值 - 这个子查询每行都执行一次，关联表没建好索引或数据量大时，就是性能瓶颈
INSERT IGNORE 和 REPLACE 不触发任何触发器
这是最容易漏掉的坑：当用 INSERT IGNORE 或 REPLACE INTO 因唯一键冲突跳过插入时，BEFORE INSERT 和 AFTER INSERT 都不会执行。
结果就是：主表没新增，但你指望触发器同步的冗余字段也没动 —— 数据看起来“一致”，其实是静默丢失了更新机会。
应对方式只有两个：
- 业务层统一走
INSERT ... ON DUPLICATE KEY UPDATE，它会触发BEFORE INSERT+AFTER UPDATE（取决于是否真更新） - 或者彻底放弃触发器，把同步逻辑提到应用层，用
@Transactional包住主表和冗余表的两次UPDATE
真正麻烦的不是语法写不对，而是你以为它在跑，其实某些路径下它根本没启动 —— 尤其在批量导入、补偿任务、幂等重试这些场景里，得反复验证触发路径是否全覆盖。
