必须将INSERT与UPDATE置于同一事务中并用子查询重算汇总值，而非简单累加；若多处需该逻辑，应使用AFTER INSERT触发器更新关联表，但禁止在触发器内操作本表。
INSERT 后触发 UPDATE 的常见错误写法
直接在 INSERT 语句后加 UPDATE 是行不通的——SQL 标准不支持一条语句里混合写入与更新操作，除非用事务包裹。很多人误以为 INSERT ... RETURNING（PostgreSQL）或 LAST_INSERT_ID()（MySQL）能自动联动更新汇总表，其实它们只返回插入值，不触发跨表逻辑。
用事务 + 显式 UPDATE 确保原子性
最通用、兼容性最好的做法是把 INSERT 和后续 UPDATE 放进同一事务里，避免中间状态被其他并发操作读到。关键点在于：先插入，再基于新数据重新计算汇总值（不是简单 +=），否则在高并发下会丢失更新。
- MySQL 示例（假设订单插入后更新客户总消费）：
START TRANSACTION; INSERT INTO orders (customer_id, amount) VALUES (123, 299.99); UPDATE customers SET total_spent = (SELECT COALESCE(SUM(amount), 0) FROM orders WHERE customer_id = 123) WHERE id = 123; COMMIT;
- 必须用子查询重算，而非
SET total_spent = total_spent + 299.99—— 因为可能有其他连接同时插入同客户订单，导致覆盖 - PostgreSQL 可用
INSERT ... RETURNING id, customer_id获取刚插入的字段，再传给后续UPDATE，但逻辑不变
用数据库原生触发器避免应用层重复逻辑
如果业务中多处插入订单都要更新客户汇总，硬编码事务容易漏改。触发器能自动响应，但要注意副作用：
- MySQL 触发器语法：
CREATE TRIGGER update_customer_total AFTER INSERT ON orders FOR EACH ROW UPDATE customers SET total_spent = (SELECT COALESCE(SUM(amount), 0) FROM orders WHERE customer_id = NEW.customer_id) WHERE id = NEW.customer_id;
- 触发器内不能对本表（
orders）做 DML 操作，否则报错；但可以安全更新其他表 - 触发器执行失败会导致整个
INSERT回滚，这是优点也是风险点——确保UPDATE语句本身不会因索引缺失或 NULL 值出错 - PostgreSQL 的触发器函数需显式定义，且注意
AFTERvsBEFORE时机
为什么不用存储过程封装？
有人倾向写一个 insert_order_and_update_total() 存储过程统一处理，但实际落地时容易踩坑：
- 不同数据库对存储过程参数类型、错误处理语法差异大（比如 MySQL 的
DECLARE EXIT HANDLER和 PostgreSQL 的EXCEPTION块） - ORM（如 Django ORM、MyBatis）调用存储过程需要额外配置，调试困难，且难以做单元测试
- 如果业务要求“插入失败时不能更新”，而存储过程里没显式事务控制，可能造成数据不一致
- 真正需要复用逻辑时，不如在应用层用函数封装事务块，比依赖数据库逻辑更可控
触发器或显式事务已经覆盖绝大多数场景，过早引入存储过程反而增加维护成本。真正复杂的情况（比如汇总涉及多级联表、异步延迟更新）才需要另起架构设计。
