根本原因是触发器依赖全表聚合（如SUM/COUNT）而未加锁，且未用OLD/NEW增量计算；应改用AFTER触发器+ON DUPLICATE KEY UPDATE或增量修正，并确保汇总表主键唯一、事务隔离一致。
触发器更新汇总表时，为什么数据总是对不上？
根本原因通常是触发器执行时机和事务隔离问题。比如在 AFTER INSERT 中读取当前表的聚合结果，但若同时有其他并发写入，COUNT(*) 或 SUM() 可能还没反映最新状态；更常见的是在触发器里直接查原表做聚合，却没加 FOR UPDATE 锁或忽略重复键冲突。
实操建议：
- 优先用
AFTER INSERT/UPDATE/DELETE，避免在BEFORE阶段修改新行再触发递归 - 汇总逻辑尽量只依赖触发事件的
NEW和OLD行，而非全表扫描（例如：插入一行就SET total = total + NEW.amount） - 如果必须查表，用
SELECT ... FOR UPDATE显式加锁，防止幻读 - 目标汇总表主键要能唯一标识统计维度（如
user_id、date），否则INSERT ... ON DUPLICATE KEY UPDATE会失效
MySQL里怎么写一个安全的订单金额汇总触发器？
假设订单表 orders 有 user_id、amount、status，要实时维护 user_stats 表中的 total_amount 和 order_count。关键不是“能不能写”，而是怎么避开主键冲突和负值陷阱。
示例（MySQL 8.0+）：
CREATE TRIGGER tr_orders_after_insert
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
INSERT INTO user_stats (user_id, total_amount, order_count)
VALUES (NEW.user_id, NEW.amount, 1)
ON DUPLICATE KEY UPDATE
total_amount = total_amount + NEW.amount,
order_count = order_count + 1;
END;注意点：
-
user_stats.user_id必须是主键或唯一索引，否则ON DUPLICATE KEY UPDATE不生效 - 删除订单时，得配一个
AFTER DELETE触发器，用total_amount = total_amount - OLD.amount回滚，不能只靠 INSERT - 如果
status影响是否计入统计（比如只统计'paid'），触发器里要加IF NEW.status = 'paid' THEN ... END IF;
PostgreSQL触发器更新汇总表，为什么老报“mutating table”错误？
PostgreSQL 没有 Oracle 那种 MUTATING TABLE 错误，但常因函数内写同一张表被锁住或触发递归而失败。典型现象是触发器里执行 UPDATE user_stats SET ... WHERE user_id = NEW.user_id，但该语句又触发另一个触发器，形成循环。
解法很直接：
- 用
NOTIFY+ 后台 worker 异步更新，彻底避开事务内写冲突 - 改用
WITH子句原子化操作：WITH upsert AS (UPDATE ... RETURNING *) INSERT ... SELECT ... FROM upsert - 禁用触发器递归：
SET session_replication_role = 'replica';在触发器函数开头临时关闭，但仅限可信场景 - 最稳的方式：把汇总逻辑抽成独立函数，用
EXECUTE 'UPDATE ...' USING NEW.user_id, NEW.amount;动态拼接，确保不触碰触发器监听的表
触发器 vs 应用层更新，什么情况下必须选触发器？
只有当数据变更路径不可控时，触发器才是必要选项——比如多个服务直连数据库、遗留系统绕过 ORM、DBA 手动执行 SQL。一旦所有写入都经过应用层，用事务内同步更新汇总表（或发 MQ 消息）比触发器更易测、易调、易回滚。
容易被忽略的硬伤：
- 触发器无法捕获
TRUNCATE操作（它不走行级触发器） - 批量导入（
LOAD DATA INFILE、COPY）可能跳过触发器，除非显式启用 - MySQL 的触发器不支持
COMMIT/ROLLBACK，出错只能靠上层事务兜底 - PostgreSQL 中触发器函数若抛异常，整个事务会回滚，但错误堆栈难定位到具体哪一行触发逻辑
真要上触发器，先确认 DBA 允许且监控已覆盖触发器执行耗时与失败率——它不是开关一开就完事的东西。
