能实现跨表同步，但必须用AFTER INSERT触发器确保自增主键等字段就绪；BEFORE仅用于校验和修改NEW值，跨表操作须严格匹配类型、避免ERROR 1442与1362。
能实现，但必须分清「同步」和「校验」两种场景，用不同触发时机、不同写法，否则大概率踩坑报错。
AFTER INSERT 是跨表同步的唯一安全时机
BEFORE INSERT 里 NEW.id 是 NULL，根本没法往目标表插主键关联数据；只有 AFTER INSERT 才能确保自增 ID、NOW()、默认值等全部就绪。
- 错误写法：
BEFORE INSERT中INSERT INTO log_table (user_id) VALUES (NEW.id)→NEW.id为空，插入失败 - 正确写法：
AFTER INSERT中用NEW.id、NEW.created_at等完整字段插入目标表 - 目标表字段类型必须严格匹配，比如源表
users.id是BIGINT UNSIGNED，目标表user_logs.user_id也得是同类型，否则隐式转换可能截断 - 禁止在
AFTER里写SET NEW.xxx = ...—— 会直接报错ERROR 1362 (HY000)
BEFORE INSERT/UPDATE 是跨表校验的合理位置
校验逻辑（比如检查用户状态、金额符号、业务规则）必须放在 BEFORE 阶段，用 SIGNAL 主动中断非法操作，而不是事后修正。
- 示例：支出流水
type = 'OUT'但amount >= 0，就在BEFORE INSERT里SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'OUT amount must be negative' - 跨表查状态要用单值子查询：
(SELECT status FROM users WHERE id = NEW.user_id)，且必须加LIMIT 1，否则多行返回直接中断 - 注意
NULL场景：如果user_id不存在，子查询返回NULL，!= 'active'判定为UNKNOWN，需显式写成IS NULL OR status != 'active' - 避免在触发器里查大表或没索引的字段，否则每行插入都拖慢主表写入
UPDATE 同步必须用 IF 判断关键字段变更
别一更新就全量同步，否则时间戳字段变一次就触发一次冗余写入。只响应真正影响业务的字段变化。
- 用
OLD.status != NEW.status判断，而不是OLD.* != NEW.*（含 NULL 时恒为 FALSE） - 字符串比较前加
TRIM()，避免空格干扰：TRIM(OLD.phone) != TRIM(NEW.phone) - 不能在触发器里
UPDATE原表（报错ERROR 1442），想改原表字段只能在BEFORE UPDATE里SET NEW.xxx = ... - 想更新另一张表？只能靠子查询赋值给
NEW字段（仅限 BEFORE），或走异步队列表 + 消费者模式
DELETE 和幂等性设计最容易被忽略
DELETE 触发器依赖 OLD，但目标表若有外键或唯一索引冲突，整个删除会回滚；更麻烦的是，INSERT IGNORE 和 REPLACE INTO 对跳过的行完全不触发任何触发器。
-
INSERT IGNORE因唯一键冲突跳过时，BEFORE/AFTER INSERT全都不执行 —— 这点线上出问题很难排查 - 目标表必须设计幂等性，比如用
(source_id, event_time)当联合唯一键，防止重复插入 - 触发器内不可
COMMIT或ROLLBACK，它没有独立事务，失败就整条语句回滚，无重试机制 - 高并发下，目标表若被长事务锁住，会拖慢源表所有 DML，批量操作尤其敏感
最常被忽视的其实是锁与事务耦合：触发器是同步阻塞执行，一旦目标表写入失败（死锁、磁盘满、约束冲突），源表操作立刻回滚——你不是在做“同步”，而是在给主流程加一道脆弱的强依赖。
