可行但须用增量修正替代全量SUM，因AFTER UPDATE触发器禁止查询或修改源表，否则报ERROR 1442；应基于OLD/NEW差值更新汇总表，并处理customer_id变更、INSERT/DELETE场景，配合合理表结构与兜底策略。
直接用触发器更新报表汇总表可行，但必须放弃“每次重算全量SUM”这种写法，否则性能崩、死锁多、还容易触发MySQL的自引用限制。
为什么AFTER UPDATE触发器不能直接查源表再UPDATE汇总表
MySQL明确禁止在触发器里修改当前正被DML操作的表——哪怕只是SELECT子查询里间接引用。比如在orders的AFTER UPDATE触发器中写SELECT SUM(amount) FROM orders WHERE customer_id = NEW.customer_id，就会报错ERROR 1442。这不是bug，是引擎级硬限制。
常见错误现象：
- 触发器执行失败，但主SQL不报错，数据状态静默不一致
- 高并发下多个订单同时更新同一客户，
SUM()子查询返回不同快照，导致total_spent反复覆盖、最终值丢失 - 子查询没走索引，拖慢主事务，锁住
orders表更久
正确做法：只做增量修正，用OLD/NEW值算差值
只要汇总字段是可加的（金额、数量、计数），就该把“重算”变成“修正”。不依赖其他行状态，也不触发额外锁。
实操要点：
- 必须判断
OLD.amount != NEW.amount，避免无意义更新引发binlog膨胀和锁竞争 - 注意
OLD.customer_id和NEW.customer_id可能不同（如订单转单），需双路更新：UPDATE customers SET total_spent = total_spent - OLD.amount WHERE id = OLD.customer_id+UPDATE customers SET total_spent = total_spent + NEW.amount WHERE id = NEW.customer_id - 如果涉及DELETE或INSERT，同样只修正：INSERT时加
NEW.amount，DELETE时减OLD.amount
汇总表结构与刷新策略怎么配才不翻车
汇总表不是视图，得自己建CREATE TABLE，且要带last_refresh字段标记时效性。别指望触发器能扛住所有场景。
关键设计点：
- 汇总表用
InnoDB引擎，确保事务一致性；主键设为业务维度（如product_id），避免重复插入冲突 - 触发器只负责“实时微调”，但无法处理历史数据修复、批量导入、或跨库同步等异常路径——这些必须靠应用层兜底或定时任务补漏
- 如果业务允许分钟级延迟，建议用
INSERT ... ON DUPLICATE KEY UPDATE配合定时增量刷新，比纯触发器更可控
最易被忽略的一点：触发器逻辑一旦写进生产库，就很难热更新。任何字段名变更、条件调整、或新增关联表，都得停写、改触发器、再验证。不如把核心修正逻辑抽到存储过程中，触发器只做简单调用，维护成本低得多。
