先说明一个关键前提：触发器不是写在哪张表上都能跑的，它的绑定对象必须是实际被业务操作修改的那张表。举个例子，如果业务逻辑是“每次修改 orders 表的 amount 字段时，自动同步 account_summary 表的 total_amount”，那么触发器就得建在 orders 上，类型也要选 AFTER INSERT、UPDATE、DELETE。把触发器写在 account_summary 上是完全没意义的，因为它不会被业务代码直接改，写在它上面不仅多余，反而会破坏数据一致性。
很多人在这一步就栽了：只覆盖了 UPDATE，漏了 INSERT 和 DELETE。可新订单插入、订单删除都会影响总和，缺一个操作，数据就会慢慢歪掉。
INSERT时：需要累加新记录中的amountUPDATE时：先减去旧值，再加上新值（注意不能只算差值，因为触发器里未必能读到OLD.amount）DELETE时：减去被删记录的amount
接着处理一个常见的陷阱：OLD.amount 在 INSERT 里不存在，NEW.amount 在 DELETE 里不存在，直接引用会报错。所以必须用 IF 或 CASE 根据操作类型做分支判断，并且对可能为 NULL 的字段显式处理。比如不能偷懒写 SET @delta = NEW.amount - OLD.amount;——这在 INSERT 或 DELETE 里直接失败。
正确的做法是：
IF TG_OP = 'INSERT' THEN SET @delta = COALESCE(NEW.amount, 0); ELSEIF TG_OP = 'UPDATE' THEN SET @delta = COALESCE(NEW.amount, 0) - COALESCE(OLD.amount, 0); ELSE -- DELETE SET @delta = -COALESCE(OLD.amount, 0); END IF;
这里的 COALESCE 是保命用的：只要任意一个 amount 为 NULL，算术结果就是 NULL，后续更新会把 total_amount 也设成 NULL，后果可想而知。
有人可能会想：直接在触发器里写 UPDATE account_summary SET total_amount = (SELECT SUM(amount) FROM orders) 多省事？但这在高并发下完全是给自己挖坑。每次触发都全表扫描 orders，数据量一上来延迟立马明显；多个并发修改还会造成“丢失更新”——两个事务同时读到旧总和，各自加完再写回，结果只累加了一次；万一 orders 上有百万行，这个 SUM() 可能锁表数秒，阻塞其他操作。
正确的姿势是只做增量更新：UPDATE account_summary SET total_amount = total_amount + @delta;。前提是 account_summary 表只有一行（或用 WHERE id = 1 精确定位），并且初始值已经通过全量计算校准过。
那触发器里能不能调用存储过程或外部函数？可以，但得极度小心。比如把校验逻辑封装到存储过程里是没问题的，但如果在里面执行 HTTP 请求、写文件，或者调用另一个会修改同一张表的触发器，就极容易陷入死锁或无限递归。
最常见的踩坑场景：在 orders 的触发器里又去 UPDATE orders——MySQL 直接报错 Can't update table 'orders' in stored function/trigger。同理，如果校验失败想抛异常，MySQL 5.7+ 要用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount mismatch';，而不是 RAISE ERROR（不支持）或者用 SELECT 模拟错误（无效）。
真正的难点其实在边界情况：amount 字段是否允许 NULL？要不要检查负数？是否要兼容部分字段更新（比如只改订单状态，不改金额）？这些逻辑只要漏判一个，触发器就会静默失效——表面不报错，数据却慢慢走样。到那时候再回头排查，可就不轻松了。
