触发器能自动更新汇总字段，但须用OLD/NEW增量计算避开自引用死循环，且需覆盖INSERT/UPDATE/DELETE三类操作，高并发下仍需应用层兜底保障一致性。
触发器能自动更新汇总字段，但必须避开自引用死循环
MySQL 的 AFTER UPDATE 触发器确实适合在行变更后同步刷新关联的汇总值（比如订单表更新后重算客户总消费），但直接在触发器里更新同一张表会报错 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。这不是权限问题，是 MySQL 的硬性限制——触发器不能修改正在被 DML 操作的表本身。
常见错误写法：
CREATE TRIGGER upd_customer_total AFTER UPDATE ON orders<br>FOR EACH ROW<br>BEGIN<br> UPDATE customers SET total_amount = (SELECT SUM(amount) FROM orders WHERE customer_id = NEW.customer_id)<br> WHERE id = NEW.customer_id;<br>END;
- 这个触发器会在每次
UPDATE orders时尝试改customers表，看起来合理，但一旦customers表上也有触发器或外键级联动作，极易引发隐式递归 - 更危险的是：如果
orders表有复合条件更新（如UPDATE orders SET status='shipped' WHERE customer_id IN (1,2,3)），触发器会为每一行都执行一次子查询 + 更新，性能陡增且结果可能不一致 - 正确做法是只做「增量修正」：用
OLD.amount和NEW.amount算出差值，再加到目标汇总字段上
用增量计算替代全量重算，避免子查询和锁竞争
实时汇总的核心不是“重新统计”，而是“响应变化”。只要业务逻辑允许汇总字段是精确差值累加（比如金额、数量类可加字段），就应放弃 SUM() 子查询，改用 OLD/NEW 值做算术修正。
示例：客户总消费字段 customers.total_spent 随订单金额变动
CREATE TRIGGER trg_orders_after_update_sum<br> AFTER UPDATE ON orders<br> FOR EACH ROW<br>BEGIN<br> IF OLD.amount != NEW.amount THEN<br> UPDATE customers<br> SET total_spent = total_spent - OLD.amount + NEW.amount<br> WHERE id = NEW.customer_id;<br> END IF;<br>END;
- 必须加
IF OLD.amount != NEW.amount判断，否则无意义更新会触发额外日志和锁 - 注意
OLD.customer_id和NEW.customer_id可能不同（比如订单转给别的客户），此时应同时减去旧客户、加给新客户——需双路更新 - 该语句不依赖事务中其他行状态，不会因并发更新同客户订单而产生幻读或覆盖，比全量
SUM更可靠
触发器无法处理 DELETE/INSERT 场景，必须配套补全
只建 AFTER UPDATE 触发器是不完整的。订单删除（DELETE）意味着要从客户总额中扣掉该笔金额；新订单插入（INSERT）则要加上。这三类操作必须全部覆盖，否则汇总值很快失真。
-
AFTER INSERT触发器只需单向加：UPDATE customers SET total_spent = total_spent + NEW.amount WHERE id = NEW.customer_id -
AFTER DELETE触发器只需单向减：UPDATE customers SET total_spent = total_spent - OLD.amount WHERE id = OLD.customer_id - 所有触发器都要考虑
customer_id为空或无效的情况，建议加IF OLD.customer_id IS NOT NULL AND OLD.customer_id > 0守卫 - 不要试图在一个触发器里兼容 INSERT/UPDATE/DELETE —— MySQL 不支持多事件触发器，强行合并会导致逻辑混乱和维护困难
高并发下仍可能丢更新，最终一致性需靠应用层兜底
即使用了增量更新，两个并发事务同时更新同一客户的订单，仍可能因读-改-写窗口导致丢失一次变更。例如：
事务 A 读得 total_spent = 1000，算出新值 1000 - 200 + 250 = 1050；
事务 B 同时读得 1000，算出 1000 - 150 + 180 = 1030；
两者先后执行 SET total_spent = ...，后者覆盖前者，实际应为 1080。
- MySQL 8.0+ 可用
UPDATE ... SET x = x + delta原子表达式规避该问题，但前提是 delta 是确定值（如NEW.amount - OLD.amount） - 更稳妥的做法是在应用层对关键汇总字段加乐观锁（如带版本号更新）或定期跑校验脚本，尤其当金额类数据敏感时
- 触发器只是辅助手段，不是强一致性保障——它快，但不绝对可靠
