mysql触发器中禁止对正在更新的表执行任何写操作，必须用old/new差值增量修正而非sum()重算；需同时实现insert/delete/update三类触发器保证一致性，并辅以应用层兜底和定期校验。
UPDATE触发器里不能直接用SUM()子查询更新目标表
MySQL会直接报错 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger，这不是权限问题，是内核级限制：AFTER UPDATE触发器中禁止对当前正被UPDATE的表执行任何写操作。哪怕你只是想查一下SUM再更新另一张表，只要语句里出现 SELECT SUM(...) FROM orders + UPDATE customers 的组合，且 orders 是触发器所在表，就可能因隐式锁或优化器路径触发该错误。
必须用OLD/NEW做差值计算，而不是重算全量
实时汇总的本质是响应变化，不是重新统计。只要字段满足可加性（如金额、数量），就该放弃 SUM()，改用增量修正：
-
OLD.amount和NEW.amount都非NULL时，差值 =NEW.amount - OLD.amount - 若
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 - 必须加
IF OLD.amount != NEW.amount THEN ... END IF;，否则无意义更新会触发额外binlog和行锁 - 不要在触发器里调用自定义函数封装SUM逻辑——照样会触发1442错误，因为函数体内仍含对触发源表的SELECT
AFTER UPDATE触发器必须覆盖INSERT/DELETE才能保证一致性
只写AFTER UPDATE，漏掉INSERT和DELETE，汇总值很快就会错。比如新订单插入没加总、订单删除没减总，客户总消费就永远不准：
- INSERT对应：用
NEW.amount加到客户汇总字段 - DELETE对应：用
OLD.amount从客户汇总字段减去 - UPDATE对应：按上述差值逻辑处理，同时考虑
customer_id是否变更 - 三类触发器共用同一套业务规则（如金额精度、空值处理），避免逻辑分散导致不一致
高并发下触发器不是银弹，得有应用层兜底
触发器能解决90%的单点变更场景，但扛不住批量更新（如 UPDATE orders SET status='paid' WHERE created_at > '2026-05-01'）或跨事务竞争。这时每行触发一次UPDATE，可能造成锁等待甚至死锁。真正稳的做法是：
- 触发器只做轻量增量修正（几行SQL，无子查询）
- 定期用校验脚本比对汇总字段和源表SUM结果，发现偏差自动修复
- 关键业务（如余额）在应用层做“先查后更+乐观锁”双保险，触发器仅作最终兜底
- 别把触发器当事务协调器——它没有跨表事务原子性保障，
UPDATE customers成功但后续应用逻辑失败，数据就裂开了
